Сервер для Привета

[tengiz]

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

Причина нехватки памяти в том, что в эти моменты резко увеличивается количество активных процессов. Это всё-таки CGI-подобное приложение или нет? В логе я видел 60+ php процессов - это что, ожидаемо? Почему вдруг лавинообразно подскакивает это количество - вот главный вопрос. Эти периоды также сопровождаются резким увеличением context switches/sec - но что здесь причина, а что следствие я пока не могу сказать. Что касается счётчиков - а Apache, PHP и MySQL вообще никаких счётчиков производительности не имеют?

[Seryi]

Причина нехватки памяти в том, что в эти моменты резко увеличивается количество активных процессов. Это всё-таки CGI-подобное приложение или нет? В логе я видел 60+ php процессов - это что, ожидаемо? Почему вдруг лавинообразно подскакивает это количество - вот главный вопрос. Эти периоды также сопровождаются резким увеличением context switches/sec - но что здесь причина, а что следствие я пока не могу сказать. Что касается счётчиков - а Apache, PHP и MySQL вообще никаких счётчиков производительности не имеют?

Я бы предположил что это какой-то из медленно выполняющихся запросов к MySQL, из-за которого выстраивается очередь из последующих запросов (php.exe).
В таком случае переход на Апач вряд ли что-то решит - надо искать какой конкретно запрос к MySQL тормозит...

[f_evgeny]

Не надо думать, трясти надо! (C). На мой взгляд, прежде. чем строить гипотезы надо попробовать Apache/module под реальной нагрузкой, тем более, что сделать это как раз легче всего.

[YellowMan]

А нельзя ли базу относительно безболезненно переконвертировать в MS SQL ? Что-что а счетчиков и возможностей найти хулигана так более чем достаточно. Тем более что я так думаю подобные исследования вполне попадают под лицензию на Developer Edition.

[vovap]

Лог передан для анализу tengiz и ещё некоторым участникам.

Логи с двумя WEB серверами? IIS и апач?

[vovap]

Причина нехватки памяти в том, что в эти моменты резко увеличивается количество активных процессов. Это всё-таки CGI-подобное приложение или нет?

CGI.

В логе я видел 60+ php процессов - это что, ожидаемо? Почему вдруг лавинообразно подскакивает это количество - вот главный вопрос.

Доступ к базы тормозится - время выполнения процесса растот. Эффект комулятивный.

Ну вот, эти антинаучные эксперименты с Апач всех запутали и испортили логи.

[f_evgeny]

Причина нехватки памяти в том, что в эти моменты резко увеличивается количество активных процессов. Это всё-таки CGI-подобное приложение или нет?

CGI.

В логе я видел 60+ php процессов - это что, ожидаемо? Почему вдруг лавинообразно подскакивает это количество - вот главный вопрос.

Доступ к базы тормозится - время выполнения процесса растот. Эффект комулятивный.

Ну вот, эти антинаучные эксперименты с Апач всех запутали и испортили логи.

Думаю, что поскольку апач стоял (стоит?) на 1333 порту и количество обращений к нему близко к нулю, на логи и статистику он никакого влияния не оказывает.

[Palych]

A chto govorit `mysqladmin extended_status` ?
Osobenno interesno naschet delayed_locks.
Esli ih mnogo - mogu navayat' hacked version of mysql4.php,
kotoraya by zamenyala INSERT na INSERT NODELAY.
Po idee eto dolzhno pomoch v bor'be s problemmoy, nauchno opisannnoj Chingizom...

P.S. Boris! Skazhi nakonec tverdoe "NET" CGI!

SAY NO TO CGI!

[Privet]

...
Я бы предположил что это какой-то из медленно выполняющихся запросов к MySQL, из-за которого выстраивается очередь из последующих запросов (php.exe).
В таком случае переход на Апач вряд ли что-то решит - надо искать какой конкретно запрос к MySQL тормозит...

Именно так я считал и так пока считаю. Помните, как-то я описывал сценерий проблемы? Моя ошибка была только в том, что я тогда не поймал того, что при блокировке активность процессора почти 0. Несмотря на это, достучатся к нему нельзя, т.к. памяти не хватает.

Боюсь, что это всё-таки mysql

Волчара, у меня стоит 2.049 и пока на нём нет такой нагрузки, чтобы заткнуть сервер.
64 запроса php, если Вы обратили внимание возникают именно в период блокировки. Это следствие, а не причина.

[A. Fig Lee]

IIS плохо работает с php module, а узкое место - похоже MySQL.
Может, вынести MySQL на тот компьютер, где больше памяти. Поставить ему литра 2.. простите гига 2. Не в очереди ли за памятью стоит MySQL?

[Privet]

f_evgeny, думаю, прав. апач никакого влияния на статистику не оказывает. Посмотрите логи. Тем более, что он там не всегда был активен.

tengiz, Palych, я пока не столь категоричен. Обратите внимание на поведение лога. Сначала идёт нарастание активности. Потом (только потом) сервер перестаёт принимать запросы. Исходящий трафик (см. на Intel) уходит в 0. Только после этого выстраивается очередь CGI процессов. Соответственно, резко увеличивается количество PHP процессов. Допускаю, что может произойти эффект положительной обратной связи. Торможение MySQL вызывает рост количества PHP процессов, которые захлопывают сервер и не дают возможности MySQL выполнить свою работу, о чём говорил f_evgeny, если я правильно его понял.
Для справки: один отсчет берётся раз в 10 секунд.

Если будет время, я постараюсь опубликовать сегодня в обед второй лог.

Какие будут предложения по набору счетчиков.

[Privet]

IIS плохо работает с php module, а узкое место - похоже MySQL.
Может, вынести MySQL на тот компьютер, где больше памяти. Поставить ему литра 2.. простите гига 2. Не в очереди ли за памятью стоит MySQL?

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

У меня есть ещё один механический вопрос. Постараюсь его задать, как будет время.

[Privet]

А нельзя ли базу относительно безболезненно переконвертировать в MS SQL ? ....

Я это уже делал и форум немного работал в такой конфигурации на тестовой машине. Самре трудное, что требует огромного времени - копирование поискового индекса. Правда, его можно и потом насчитать, но это потребует несколько недель, если не больше.

[katit]

Может немного не в тему, может это уже сделано...
http://phpbb.com/phpBB/viewtopic.php?t=135383

мне кажется там много чего полезного есть

[f_evgeny]

Давайте попытаемся рассчитать несколько цифр. Не помню, какой комп на привете, поэтому буду считать для компа, который я тестировал (K-6-500,256M RAM).
Исходные данные возьмем из опубликованных на форуме:

Code: Select all

Page         Count   Rate%   Interval
download.php      431   0.850971   0:01:47
index.php         7947   15.69065   0:00:08
login.php         1422   2.807613   0:00:43
posting.php      3065   6.051572   0:00:20
search.php      906   1.788817   0:01:08
viewforum.php      13181   26.02472   0:00:05
viewtopic.php      23696   46.78566   0:00:03
         50648       

Если я правильно понял, 50648 - общее число запросов
за 70% суток. Это дает нам:
> 50648/(24*0.7*60*60)
~.83743386243386243386
запросов/секунда. Примем грубо, что в "пиковое" время" частота запросов в 10 - 15 раз выше, чем в среднем. Получаем,
что в "пиковое время" частота запросов:
.83743386243386243386*(10-15) ~8-12 запросов/секунда.
Теперь сравним с тестом:

Code: Select all

Win,IIS,CGI,PHP,5000                                                                       
single - ? сек, 100%,Залипает, Не смог закончить тест, судя по темпу д.б.564 сек           
multy5 - 150 сек, 100%  Иногда один из процессов залипает                                 
multy20- 100 сек, 100%, Иногда один из процессов залипает           

Большой разброс, но прикинем, что при 100% загрузке процессора, компьютер может обработать примерно:
5000/150
~33.33333333333333333333
запросов/секунда

Сравниваем два результата и видим, что величины 8-12 и 33 одного порядка. На мой взгляд, можно сделать вывод, что при работе на K-6-600 в конфигурации CGI значительная часть времени процессора уйдет на запуск CGI.