Поставил ограничение по загрузке процессора

 
+
-
edit
 

Balancer

администратор
★★★★☆
Поставил на форумах ограничение по загрузке процессора. Текущую загрузку можно оценить на любой странице форума снизу-справа. Возможно, это несколько облегчит ситуацию.

Под это дело вернул пока не модифицированный поиск.
 
Это сообщение редактировалось 27.04.2004 в 16:00
RU Фагот #27.04.2004 16:50
+
-
edit
 

Фагот

координатор
★★
Это с этим связано то, что сообщения не всегда постятся?
 
+
-
edit
 

Balancer

администратор
★★★★☆
Фагот, 27.04.2004 16:50:34 :
Это с этим связано то, что сообщения не всегда постятся?
 


При отказе доступа из-за перегрузки сервера он так прямо и пишет:
Обнаружена ошибка:

Сервер в настоящее время ПЕРЕГРУЖЕН и не может выполнить Ваш запрос. Попробуйте позже.
 

Если не постится с иными признаками - значит, что-то ещё глючит. Описывай подробнее, попробую разобраться.
 
RU Фагот #27.04.2004 17:03
+
-
edit
 

Фагот

координатор
★★
Не-не... всё именно так :)

А надолго это? А то не очень удобно :)
 
+
-
edit
 

Balancer

администратор
★★★★☆
Фагот, 27.04.2004 17:03:33 :
А надолго это? А то не очень удобно :)
 


Наверное, пока памяти не докуплю и не поставлю.
 

Vale

Сальсолёт

На странице "новые сообщения" - [ Server Load: 155% ]
;)
А на этой- 98% :D
"Не следуй за большинством на зло, и не решай тяжбы, отступая по большинству от правды" (Исх. 23:2)  
+
-
edit
 

Balancer

администратор
★★★★☆
Vale, 27.04.2004 17:15:04 :
На странице "новые сообщения" - [ Server Load: 155% ]
;)
А на этой- 98% :D
 


дык, результат-то показывается на момент создания страницы. Пока эту загружал - сервер немного разгрузился :)
 
RU Alesandro #27.04.2004 17:20
+
-
edit
 

Alesandro
Серокой

координатор
★★★
У меня сейчас 118%. Как нагрузка выше ста быть может?
Больше не раскалятся ваши колосники. Мамонты пятилеток сбили свои клыки. ©  
+
-
edit
 

Balancer

администратор
★★★★☆
Alesandro, 27.04.2004 17:20:09 :
У меня сейчас 118%. Как нагрузка выше ста быть может?
 


Потому что это не загрузка процессора, а "загрузка сервера" :) От условной предельной загрузки, пока ещё не начинает сильно тормозить.

Реальная загрузка процессора в 20 раз меньше, но стоит помнить, что уже при реальных 15% наступает почти мёртвый вис.

При загрузке процессора менее 5% - всё шустрит. При 5..10% - тормозит, но ещё живёт. Выше - смотря под что ушли эти проценты.
 
RU AlexanderIpp #29.04.2004 08:48
+
-
edit
 

AlexanderIpp

втянувшийся

GZIP отключите
И ищите бесконечные циклы/вызовы подпрограмм в скриптах.
Не может в обычном режиме такого быть при стандартной загрузке куда меньшей.
Сами не летаем и другим не дадим © Войска ПВО
 
+
-
edit
 

Balancer

администратор
★★★★☆
AlexanderIpp, 29.04.2004 08:48:52 :
GZIP отключите
 


При пиковой загрузке - всего несколько процентов CPU :)

Кстати, если его отключить, загрузка на сервер ЗАМЕТНО возрастёт. Результаты запросов будут отдаваться в 5..7 раз медленнее, соответственно, процессы будут жить в 5..7 раз дольше.

>И ищите бесконечные циклы/вызовы подпрограмм в скриптах.

Нету их :D
Я же расписал в параллельном топике источники проблем. MySQL.
Копаться в его исходниках? :D

>Не может в обычном режиме такого быть при стандартной загрузке куда меньшей.

Да нет, всё нормально. Я же написал чуть выше, что загрузка показывается условная, а не CPU. Просто по наблюдению, при интенсивности обращений, при которой загрузка CPU достигает реальных 10%, MySQL перестаёт справляться с запросами и машина уходит в своп.
 
RU AlexanderIpp #29.04.2004 20:21
+
-
edit
 

AlexanderIpp

втянувшийся

При пиковой загрузке - всего несколько процентов CPU
 

Тогда точно ищите баги.
Кстати, если его отключить, загрузка на сервер ЗАМЕТНО возрастёт. Результаты запросов будут отдаваться в 5..7 раз медленнее, соответственно, процессы будут жить в 5..7 раз дольше.
 

Ну это смотря где узкое место.
Я же расписал в параллельном топике источники проблем.
 

А я его читаю? :D
Ну очень проблема похожая, было у меня такое. Без всякого MySQL на текстовых файлах ака флатах. :D
Найти было очень трудно, хостер был очень рад, когда скрипт периодически (раз в месяц где-то) почти пускал сервер со всеми сайтами в даун. Потом совместными усилиями нашли таки проблему. Было бы смешно, если бы не было так грустно... Промудохались полмесяца, а оказалось - подпрограмма вывода ошибки вызывала в определённой ситации подпрограмму вызхова ошибки, причём сиутация была связана с куками. Понятное дело, что это безобразие повторялось бесконечно, при это записывая честно отчёт в лог ошибок конференции. Итог понятен - за несколько минут сервер грузился под завязку. Лог этот вырастал в зависимости от того, когда админ убивал процесс, то до 150-300мб, то до 3 гб. :D А мы ещё на DoS грешили...
По поводу MySQL - ну, скажем так, всё может быть, но в принципе бывают форумы и побольше на нём, ничего, живут... Я со многими людьми разговаривал, кто на нём уже много лет пишет - никогда такого не слышал. Хватает у него недостатков, но не настолько же.
Впрочем, вам конечно виднее, я же не имею данных по функционированию сервера.
Так сказать мимоходом заметил.
Я же написал чуть выше, что загрузка показывается условная, а не CPU.
 

Да это конечно понятно (впрочем, эту загрузку по-моему сам *nix вываливает, так что...), но сервер тут тоже не 486SX... Тем паче что когда эта радость происходит (был пару раз очевидцем), script execution time вырастает до неприличия. Даже для ошибки при 200% загрузки.
Сами не летаем и другим не дадим © Войска ПВО
 
+
-
edit
 

Balancer

администратор
★★★★☆
Ну, тогда повторю на счёт MySQL, если параллельный топик читать лениво :)

Всё дело тормозит поиск. Поиск идёт долго, т.к. он не на FULLTEXT-индексах (глюки с ними - отдельная песня) а на обычном LOWER(field) LIKE %search_word%. Перешарить так 500Мб - это минут до 10 работы. Чтению это не мешает, но вот записывать в таблицу, по которой идёт поиск ничего нельзя. При попытках записать происходит залочка запроса. И таблицы в целом, т.к. последующие запросы даже на чтение должны читать уже изменённые данные. Вот и выходит - пока идёт поиск - всё хорошо. Как при этом ещё и кто-то что-то напишет - всё, до конца поиска все остальные сидят и ждут. Косвенный признак этого - рост потребления CPU-ресурса.

Впрочем, поиск я временно вырубил вообще.
 
RU AlexanderIpp #30.04.2004 08:09
+
-
edit
 

AlexanderIpp

втянувшийся

Гм, ну сейчас например 40% загрузки показывает и без поиска...
Ну в принципе понятно, разве что удивляет то, что поиск не разбит на поиск по отдельным разделам. Надо учесть будет при разработке своего нового движка сиё наблюдение. :)
Кстати, вот и плюс flat'ов... там с этим проще... flock, записали/считали, close, и пошли работать...
PS Ну и неудобная форма ответа...
Сами не летаем и другим не дадим © Войска ПВО
 

BrAB

аксакал
★☆
Balancer, 27.04.2004 14:54:03 :
Текущую загрузку можно оценить на любой странице форума снизу-справа.
 


Ром, а не дашб ссылку где взять такую штуку? хочется себе поставить, а найти не могу :-(
Было у еврея всё плохо. Пришел за советом к равину. Тот - напиши над дверью - "Так будет не всегда". Стало всё ок. Пошел он благодарить. А тот ему - надпись не стирай. Злой чечен ползет на берег. ©Лермонтов  
+
-
edit
 

Balancer

администратор
★★★★☆
AlexanderIpp, 30.04.2004 08:09:20 :
Гм, ну сейчас например 40% загрузки показывает и без поиска...
 


Ну так, естествено. Средняя загрузка Базы - около 50 тыс. MySQL-запросов в час.

>Ну в принципе понятно, разве что удивляет то, что поиск не разбит на поиск по отдельным разделам.

С разбивкой на разделы очень усложняется сквозная работа с форумом. Например, определение форума по топику и т.п. Вообще, запросов к базе при разбивке будет больше. Другое дело, что поиск будет только один форум завешивать, а не все, но это всё равно из катеогрии припарок мёртвому. Надо просто переделывать поиск :)

>Надо учесть будет при разработке своего нового движка сиё наблюдение. :)
>Кстати, вот и плюс flat'ов... там с этим проще... flock, записали/считали, close, и пошли работать...

Угу. Напомнить, во что выливается поиск по флатам? :D
А хотя бы просто поддерживать всю структуру форума? Кто куда во сколько ответил и т.п. Параллельно приходится содержать кучу информации и т.п. Замечу, что флатфайловая UBB, которая стояла до iBF, при загрузке раз в 10 меньшей напрочь убивала сервер :D

>PS Ну и неудобная форма ответа...

Ну так это уже надо просто скин ковырять. А мне просто лень этим заниматься, учитывая, что будет переезд на версию 2.0 со своими скинами.
 
RU AlexanderIpp #01.05.2004 18:57
+
-
edit
 

AlexanderIpp

втянувшийся

Ну так, естествено. Средняя загрузка Базы - около 50 тыс. MySQL-запросов в час.
 

Мне кажется, что обычно загрузка где-то процентов 10, ну да ладно. понаблюдаю ещё. :)
Да и вам опять же виднее, у вас статистика. :)
Кстати, циферок можно - загрузка памяти, проца и т.п.?
Для себя опять же, учесть чужой опыт.
С разбивкой на разделы очень усложняется сквозная работа с форумом.
 

Ну это смотря как делать. Конечно, сложнее, но в лоб всегда проще в общем-то...
Например, определение форума по топику и т.п.
 

Зачем?
Просто надо иметь место, куда будут скидываться результаты, а дальше просто выполнять те же запросы, меняя WHERE номер_форума=текущий номер.
Другое дело, что поиск будет только один форум завешивать, а не все, но это всё равно из катеогрии припарок мёртвому.
 

Учитывая количество форумов на данной конференции, я бы так не сказал.
Угу. Напомнить, во что выливается поиск по флатам?
 

Тупой перебор с проверкой по регекспам.
Только базу не блокирует. :)
Замечу, что флатфайловая UBB, которая стояла до iBF, при загрузке раз в 10 меньшей напрочь убивала сервер
 

Ну так есть forum.ixbt.com, есть, к примеру, forum.oszone.net... Тоже ничего себе размерчик. Работает более-менее. forum.ru-board.com на DBM (модуль db_file.pm) опять же, тоже недалеко от флатов ушёл, если задуматься... При этом он, судя по всему, не блещет большой оптимизацией, админы там не слишком профессиональные, а кто профи был - его выгнали с позором. :D
Конечно, зависит от того, как писать, но, тем не менее, тоже вариант. Хотя целостность данных в чём-то обеспечить сложнее.
Ну так это уже надо просто скин ковырять. А мне просто лень этим заниматься, учитывая, что будет переезд на версию 2.0 со своими скинами.
 

Не факт, что это будет слишком скоро... Она, по-моему, ещё тестируется. Если вспоминить, сколько в RC находилась сначала IB3 (RC, кажется, аж три штуки было...), а потом и IBF1, то вряд ли есть повод для оптимизма...
По поводу как сделать показ загрузки - ну на Perl'е это выглядит так:
code text
  1.            open (LOAD, '/proc/loadavg') or { $load = 'недоступно' };
  2.            $load = substr(<LOAD>, 0, 5) unless ($load eq 'недоступно');
  3.            close LOAD;

$load всатвить куда надо. В windows, понятное дело, не работает.
На PHP сами портируйте, я его почти не знаю.
Сами не летаем и другим не дадим © Войска ПВО
 
+
-
edit
 

Balancer

администратор
★★★★☆
AlexanderIpp, 01.05.2004 18:57:01 :
Кстати, циферок можно - загрузка памяти, проца и т.п.?
 


Сейчас:
code text
  1. [root@airbase root]# free
  2.              total       used       free     shared    buffers     cached
  3. Mem:        515732     484260      31472          0      32880     204308
  4. -/+ buffers/cache:     247072     268660
  5. Swap:      1044216     115064     929152


Если в свопе оказывается занято под 150Мб - начинаются подтормозки. При 200Мб - очень серьёзные. При 250 - система почти виснет :)

Проц - очень зависит от прочих факторов. Сейчас
code text
  1. [root@airbase root]# cat /proc/loadavg
  2. 1.32 1.70 1.80 2/154 24747
  3. [root@airbase root]# cat /proc/loadavg
  4. 1.30 1.69 1.79 2/153 24748
  5. [root@airbase root]# cat /proc/loadavg
  6. 1.30 1.69 1.79 2/151 24749
  7. [root@airbase root]# cat /proc/loadavg
  8. 1.30 1.69 1.79 2/149 24750


Кстати, собственно, почему полез в этот топик - вчера видел пару раз "форумную загрузку" всего в 2% :)

>>С разбивкой на разделы очень усложняется сквозная работа с форумом.
>Ну это смотря как делать. Конечно, сложнее, но в лоб всегда проще в общем-то...

Да как ни делай :D
Проще уж поиск вынести отдельно (что сейчас и делаю) и некоторые запросы реорганизовать. Т.к. для простых запросов 400тыс. строк на MySQL - это игрушки.

>>Например, определение форума по топику и т.п.
>Зачем?

Главная идеология Авиабазы - сохранение работоспособных ссылок.
Чтобы человек мог разместить где-то ссылку на какой-то ресурс и не париться потом, где она лежит. Теперь представь, что нет сквозной нумерации постингов. Кто-то кидает ссылку на постинг где-то в другом месте. А мы тут открываем новый подфорум и перебрасываем топик туда. Или вообще он в архив уходит. Люди потом кликают по ссылке и попадают на популярную 404-ю страницу :) "Где моя колбаска?!". Некрасиво :)

>Учитывая количество форумов на данной конференции, я бы так не сказал.

Основная загрузка идёт по 2..3 форумам :D
Так что - всё равно не принципиально.

>Тупой перебор с проверкой по регекспам.
>Только базу не блокирует. :)

Я такой же перебор и в БД могу организовать. Не по `field` LIKE '%mask%' искать, а тупо считывать значения всей базы в цикле и искать в ней. И блокировать не будет, и быстрее, чем с флатами будет :)

>Ну так есть forum.ixbt.com

Более глючный форум на сегодня трудно найти. Я пасусь там очень регулярно, и столь же регулярно матерюсь и трачу невосполнимый ресурс в виде нервов :)

>есть, к примеру, forum.oszone.net...

Посмотрел сейчас. Но там всего 211 тыс. сообщений. Когда на Авиабазе было ~290тыс - тут всё летало без единого нарекания, проблемы после ~300 тыс. начались :D

>Работает более-менее. forum.ru-board.com

Он гораздо "менее", чем "более" :D:D
Тоже бываю там регулярно и хорошо помню их периодические тормоза и глюки :D

>на DBM (модуль db_file.pm) опять же, тоже недалеко от флатов ушёл, если задуматься...

Повторюсь снова, что в таком же режиме и с БД можно работать. И ещё быстрее будет :D Я проводил в своё время тестирование - простая выборка файла из DBM быстрее, чем из флатфайла, но из MySQL ещё быстрее. Разница между флатфайлом и MySQL - в несколько раз :)

>При этом он, судя по всему, не блещет большой оптимизацией, админы там не слишком профессиональные, а кто профи был - его выгнали с позором. :D

Ну, чёрт его знает. :)

>Не факт, что это будет слишком скоро...

PDR2 уже вышел.

>Она, по-моему, ещё тестируется.

Если бы в RC вышел - я бы уже и переезд, наверное, учинил :D

>Если вспоминить, сколько в RC находилась сначала IB3 (RC, кажется, аж три штуки было...), а потом и IBF1, то вряд ли есть повод для оптимизма...

Так пока и на 1.2 посидим :)

>По поводу как сделать показ загрузки - ну на Perl'е это выглядит так:

Да вот на форуме этом так и делается :D
 
+
-
edit
 

Balancer

администратор
★★★★☆
Лучше поделитесь, откуда получают статистику такого вида:

code text
  1. Top Process %CPU 19.3 httpd [www.crimea-board.tarifov.net] [/gal/thumbnails.php?album18&page6&sortda]
  2. Top Process %CPU 15.9 httpd [www.crimea-board.tarifov.net] [/forums/index.php?s&actST&f8&t167&st15]
  3. Top Process %CPU 10.3 httpd [www.crimea-board.tarifov.net] [/forums/index.php?s&actST&f24&t1027&st0]


Т.е. с раскладкой по http-запросам? top -c выдаёт только сам httpd с обрезанной командной строкой...
 
LT Bredonosec #06.05.2004 00:43
+
-
edit
 

Bredonosec

аксакал
★★★☆

Красивые циферьки показываете.. У меня хронически видно такое:
[ Server Load: 111,8% ]
 
- Это прямо ща, с подвала окна скопировал. Навскидку за последние пару дней поню значения 107, 103, 109% (копейки не запоминал :p )
 
LT Bredonosec #06.05.2004 01:08
+
-
edit
 

Bredonosec

аксакал
★★★☆

[quote]http://www.crimea-board[/quote - А почему бы вам не спросить об этом напрямую хозяина того форума? (Роман Колесник, техцентр ABC компьютеры, Симферополь, ник (искать в инете) - dekker )
Он человек нормальный, так что, не думаю, что откажется говорить ;)
Да, их хостер, под ником tarifov.net тоже бродит на том форуме, так что его можно там поймать по этому вопросу.
 

в начало страницы | новое
 
Поиск
Поддержка
Поддержи форум!
ЯндексЯндекс. ДеньгиХочу такую же кнопку
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru