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

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

Под это дело вернул пока не модифицированный поиск.

Это с этим связано то, что сообщения не всегда постятся?

Фагот, 27.04.2004 16:50:34 :

Это с этим связано то, что сообщения не всегда постятся?

 

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

Обнаружена ошибка:

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

 

Если не постится с иными признаками - значит, что-то ещё глючит. Описывай подробнее, попробую разобраться.

Не-не... всё именно так

А надолго это? А то не очень удобно

Фагот, 27.04.2004 17:03:33 :

А надолго это? А то не очень удобно

 

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

На странице "новые сообщения" - [ Server Load: 155% ]

А на этой- 98%

Vale, 27.04.2004 17:15:04 :

На странице "новые сообщения" - [ Server Load: 155% ]

А на этой- 98%

 

дык, результат-то показывается на момент создания страницы. Пока эту загружал - сервер немного разгрузился

У меня сейчас 118%. Как нагрузка выше ста быть может?

Alesandro, 27.04.2004 17:20:09 :

У меня сейчас 118%. Как нагрузка выше ста быть может?

 

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

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

При загрузке процессора менее 5% - всё шустрит. При 5..10% - тормозит, но ещё живёт. Выше - смотря под что ушли эти проценты.

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

AlexanderIpp, 29.04.2004 08:48:52 :

GZIP отключите

 

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

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

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

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

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

Да нет, всё нормально. Я же написал чуть выше, что загрузка показывается условная, а не CPU. Просто по наблюдению, при интенсивности обращений, при которой загрузка CPU достигает реальных 10%, MySQL перестаёт справляться с запросами и машина уходит в своп.

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

 

Тогда точно ищите баги.

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

 

Ну это смотря где узкое место.

Я же расписал в параллельном топике источники проблем.

 

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

Я же написал чуть выше, что загрузка показывается условная, а не CPU.

 

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

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

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

Впрочем, поиск я временно вырубил вообще.

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

Balancer, 27.04.2004 14:54:03 :

Текущую загрузку можно оценить на любой странице форума снизу-справа.

 

Ром, а не дашб ссылку где взять такую штуку? хочется себе поставить, а найти не могу :-(

AlexanderIpp, 30.04.2004 08:09:20 :

Гм, ну сейчас например 40% загрузки показывает и без поиска...

 

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

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

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

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

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

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

Ну так это уже надо просто скин ковырять. А мне просто лень этим заниматься, учитывая, что будет переезд на версию 2.0 со своими скинами.

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

 

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

С разбивкой на разделы очень усложняется сквозная работа с форумом.

 

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

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

 

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

Другое дело, что поиск будет только один форум завешивать, а не все, но это всё равно из катеогрии припарок мёртвому.

 

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

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

 

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

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

 

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

Ну так это уже надо просто скин ковырять. А мне просто лень этим заниматься, учитывая, что будет переезд на версию 2.0 со своими скинами.

 

Не факт, что это будет слишком скоро... Она, по-моему, ещё тестируется. Если вспоминить, сколько в RC находилась сначала IB3 (RC, кажется, аж три штуки было...), а потом и IBF1, то вряд ли есть повод для оптимизма...
По поводу как сделать показ загрузки - ну на Perl'е это выглядит так:

1.            open (LOAD, '/proc/loadavg') or { $load = 'недоступно' };
2.            $load = substr(<LOAD>, 0, 5) unless ($load eq 'недоступно');
3.            close LOAD;

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

AlexanderIpp, 01.05.2004 18:57:01 :

Кстати, циферок можно - загрузка памяти, проца и т.п.?

 

Сейчас:

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 - система почти виснет

Проц - очень зависит от прочих факторов. Сейчас

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%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PDR2 уже вышел.

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

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

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

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

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

Да вот на форуме этом так и делается

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

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 с обрезанной командной строкой...

Красивые циферьки показываете.. У меня хронически видно такое:

[ Server Load: 111,8% ]

 

- Это прямо ща, с подвала окна скопировал. Навскидку за последние пару дней поню значения 107, 103, 109% (копейки не запоминал )

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