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

[f_evgeny]

Ну вот, я и есть профессионал. И вот мое мнение: бесполезно о чем-либо разговаривать, пока система работает на CGI. Только избавившись от него, можно анализировать ситуацию. А с CGI ресурсы тратятся просто на запуск/уничтожение процессов.

f_evgeny, логи не подтверждают Вашей гипотезы - затык и в первом и во втором случае "залипания" в выложенном логе произошёл из за того, что было запущено слишком много экземпляров PHP. Если бы проблема была в долгом их запуске, то картина выглядела бы совершенно иначе: мы бы видели зашкал CPU как раз в коде ядра, а пользовательские процессы, включая PHP, MySQL, IIS сидели бы и сосали лапу. Однако в реальности всё было иначе - в первом "залипании" CPU вообще ушёл в 0, во втором, MySQL (в основном) и PHP весело шуршали на пару. Да только не над тем, над чем надо.

А вообще, пожалуйста, читайте внимательно то, что пишут другие профессионалы. Демонстративное игнорирование чужого, причём, аргументированного, мнения - совершенно непрофессионально.

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

[tengiz]

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

Под детским велосипедом имеется в виду MySQL? Или это скорее инвалидная коляска?

P.S. Прежде чем менять колесо нужно хотя бы попытаться понять, что же на самом деле происходит.

P.P.S. Фрагмент из бородатого автомобильного анекдота: А ты капот открывал? Да. А по колесу стучал? Стучал. Ну тогда не знаю, что и делать.

P.P.P.S. Отчего же они - в смысле братцы-опенсорсники - такие постоянно сердитые

[f_evgeny]

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

Под детским велосипедом имеется в виду MySQL? Или это скорее инвалидная коляска?

P.S. Прежде чем менять колесо нужно хотя бы попытаться понять, что же на самом деле происходит.

P.P.S. Фрагмент из бородатого автомобильного анекдота: А ты капот открывал? Да. А по колесу стучал? Стучал. Ну тогда не знаю, что и делать.

P.P.P.S. Отчего же они - в смысле братцы-опенсорсники - такие постоянно сердитые

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

[Siberian Cableman]

Ключевой вопрос как ставнивать половины: vasjapupkin.com и microsoft.com используют MySQL и MSSQL соответственно, так что можно сделать вывод что 50% компаний из нашего списка используют MySQL .

А если по делу, Евгений поверьте Тенгизу, ему по роду службы надо уметь распутывать подобные вещи. У него уже глаз набит на это. К тому же у него есть лог, чего у Вас нету . Ну я понимаю, что Вам ненавистно слово, Микрософт, но не только Вам. Наш CEO Ed Zander, который прилетал из Чикаго сегодня потoлковать со Стивом Балмером, и заодно заскочил к нам на 30 минут что бы встретится с народом, тоже Микрософт не любит, так что Вы в хорошей компании, не волнуйтись. Ну нету у нас человека из Oracle Engine, нету, так что прийдется воспользоватся знаниями Тенгиза.

[f_evgeny]

Ключевой вопрос как ставнивать половины: vasjapupkin.com и microsoft.com используют MySQL и MSSQL соответственно, так что можно сделать вывод что 50% компаний из нашего списка используют MySQL .

А если по делу, Евгений поверьте Тенгизу, ему по роду службы надо уметь распутывать подобные вещи. У него уже глаз набит на это. К тому же у него есть лог, чего у Вас нету . Ну я понимаю, что Вам ненавистно слово, Микрософт, но не только Вам. Наш CEO Ed Zander, который прилетал из Чикаго сегодня потoлковать со Стивом Балмером, и заодно заскочил к нам на 30 минут что бы встретится с народом, тоже Микрософт не любит, так что Вы в хорошей компании, не волнуйтись. Ну нету у нас человека из Oracle Engine, нету, так что прийдется воспользоватся знаниями Тенгиза.

1. Привет - это типичный vasjapupkin.com. Значит, надо и смотреть, какие решения используют такого типа сайты.
2. При чем здесь Майкрософт?

[f_evgeny]

Дупль

[YellowMan]

О ! Вот что значит вовремя ляпнуть очередную глупость мимоходом - и уже похоже у нас будет нормальная база с нормальной документацией, поддержкой, кучей ресурсов и достаточно большим количеством опытных людей, вполне осознающих что и зачем стоит делать чтобы по крайней мере датабазная часть форума не вызывала вопросов и подозрений.
Хорошая тенденция - мне нравиться !

[f_evgeny]

Очень похоже, что многие просто не понимают смысл термина CGI.

[Seryi]

Очень похоже, что многие просто не понимают смысл термина CGI.

Евгений, думаю все отлично понимают что-такое CGI и какие недостатки есть у CGI. Просто исходя из счетчиков производительности - похоже на то что проблема совсем не в CGI, а в MySQL.
Если это так то отказ от CGI сейчас ситуацию абсолютно не исправит, а только запутает.

[vovap]

И вот мое мнение: бесполезно о чем-либо разговаривать, пока система работает на CGI. Только избавившись от него, можно анализировать ситуацию.

Так это то же самое, чо "ставь SQL и все"

[vovap]

Согласно первому логу проблема действительно скорее в СУБД, хотя я всё равно не могу 100% это утверждать.

Кстати, еще один ресурс, что юзают процессы - это канал.
Вот интересно, что получится, если они пытаются пропихнуть по нему больше, чем может пролезть.
Там в логе наверное должно быть - сколько в канал лезет?

[vovap]

Если это так то отказ от CGI сейчас ситуацию абсолютно не исправит, а только запутает.

Ну запутать он не запутает, скорее наоборот. За одним процессом следить будет легче. Вообще одно другому не мешает. Апач стоит и вроде работает Ок - то есть менять можно хоть сегодня. Разговор за то, чтобы на новый сервер поставить уже SQL server.

[f_evgeny]

Очень похоже, что многие просто не понимают смысл термина CGI.

Евгений, думаю все отлично понимают что-такое CGI и какие недостатки есть у CGI. Просто исходя из счетчиков производительности - похоже на то что проблема совсем не в CGI, а в MySQL.
Если это так то отказ от CGI сейчас ситуацию абсолютно не исправит, а только запутает.

- Подскажите, какие счетчики включать, чтобы посмотреть затраты ядра на запуск процессов. Я не нашел.
- Я тут потестировл немного вебсервера в условиях близких к боевым и наблюдал такой эффект - с регулярной периодичностью в условиях максимальной нагрузки (загрузка - запуск CGI) загрузка падает до 0 и ядро (я так думаю, что это ядро) чего то ждет по две-три секунды. Я тут недавно думал, что это связано с открытием/закрытием сокетов, но подумав немного, отказался от этой мысли. Теперь я думаю, что это связано с запуском большого количества процессов.
- отказываться от CGI надо всегда, когда есть такая возможность.

[f_evgeny]

И вот мое мнение: бесполезно о чем-либо разговаривать, пока система работает на CGI. Только избавившись от него, можно анализировать ситуацию.

Так это то же самое, чо "ставь SQL и все"

Не совсем. Тут не важно, майкрософт, не майкрософт, черт лысый, сегодня все хорошо знают, при нагрузке выше, чем совсем низкая, надо отказываться от CGI.

[Palych]

Поскольку мой категоризм начинает рассеиваться - приведу пару фактов.

1. Попробовал добавить INSERT DELAYED - не работает вообще. Запросы попросту игнорируются. К тому же документация гласит что в случае MyISAM ето практически бесполезно;
2. Попробовал persistent - вроде работает, поведение под нагрузкой не сравнивал. Однако вот что гласит PHP site:
http://www.php.net/manual/en/function.m ... onnect.php

03-Feb-2004 04:19
Normally you do NOT want to use mysql_pconnect. This function is designed for environments which have a high overhead to connecting to the database. In a typical MySQL / Apache / PHP environment, Apache will create many child processes which lie in idle waiting for a web request to be assigned to them. Each of these child processes will open and hold its own MySQL connection. So if you have a MySQL server which has a limit of 50 connections, but Apache keeps more than 50 child processes running, each of these child processes can hold a connection to your MySQL server, even while they are idle (idle httpd child processes don't lend their MySQL connection to other httpd children, they hold their own). So even if you only have a few pages which actually connect to MySQL on a busy site, you can run out of connections, with all of them not actually being used.

In general use mysql_connect() for connecting to MySQL unless that connection takes a long time to establish.

[Palych]

Теперь попробую сделать какой-нибудь вывод...
...Сделал:

Я склоняюсь к тому что ето злой конвой. Очень уж Тенгиз славно все описал.

Только мне думается что оно не так фатально в смысле борьбы с етим злом. Естественно на 100% предотвятить ето не возможно, но снизить до ничтожной вероятности наверное можно.

Главная задача - снизить время выполнения запросов.
Здесь могут помочь трюки типа описанных на ПХПББшном форуме.

Чтобы бить наверняка - думаю надобно наваять некий профайлер, который будет составлять хит парад самых медленных запросов. Если коллективный разум увидит ети запросы, он наверняка что-нибудь придумает как их улучшить....

Пойду посмотрю что можно в ПХП на ету тему сделать...

[Dmitry67]

Insert DELAYED гениальная команда
Почему такой нет в MS SQL ?
tengiz, надо имплементировать ее, а также (записывайте)

Code: Select all

update YourBankAccount set Amount=Amout+@delta ...
  option(if_server_will_have_time)

select Approximate sum(Amount) from Accounts  

set disable_all_transactions_to_avoid_deadlocks on

set hint_readuncommitted_by_default_for_all_tables_to_make_it_run_faster on

[katit]

Да, вот это здорово, это по нашему! Неважно, в чем дело, ставим MS SQL и все полетит! Только куда?

Во-первых про CGI (как уже писали) все догадываются.
Во-вторых (как уже писали) Это не есть проблема.

Судя по всему проблема в MySQL. А для большинства здесь это черный ящик. Поетому реч идет про SQL Server где есть все необходимое для того чтобы найти затычку. Также имеются люди которые смогут реально поправить эту проблему.

[tengiz]

- Подскажите, какие счетчики включать, чтобы посмотреть затраты ядра на запуск процессов. Я не нашел.

Начните с CPU Utilization - Kernel time.

- Я тут потестировл немного вебсервера в условиях близких к боевым и наблюдал такой эффект - с регулярной периодичностью в условиях максимальной нагрузки (загрузка - запуск CGI) загрузка падает до 0 и ядро (я так думаю, что это ядро) чего то ждет по две-три секунды.

Если при запуске процесса нужно проверять права пользователя на другой машине (например, когда нужно дождаться ответа от контроллера домена) то действительно можно нарваться на ожидание. Но если ядру нужды локальные ресурсы, то это очевидным образом проявится - подскочит CPU%, увеличится подкачка, подскочет дисковая активность и пр.

- отказываться от CGI надо всегда, когда есть такая возможность.

Конечно, только в реальности есть ещё приоритеты, который профессионал должен уметь правильно расставить. Я практически уверен, что если даже убрать MySQL и поставить Oracle, знатоков которого судя по всему здесь навалом, рано или поздно встанет проблема с CGI. Но сейчас это не выглядит первоочередной головной болью.

А сейчас нужно понять, что происходит с приложением, т.е. со всеми его компонентами. Обратитесь к помощи сообщества - попробуйте задействовать распределённого эксперта по PHP/MySQL, если что-то путное выйдет и самая острая проблема снимется, то всем будет проще. А то которую уже страницу толчём воду в ступе без реальной отдачи.

[f_evgeny]

... в реальности есть ещё приоритеты, который профессионал должен уметь правильно расставить....

Сегодня у моей мамы день рождения, поэтому я сегодня добрый.
Поэтому я не ругаюсь, а объясняю. В данном случае, правильно расставленные приоритеты - это и есть в первую очередь отказ от CGI, а потом уже все остальное.
И если Вы с этим не согласны, то значит или, у Вас есть тайные мотивы, или Вы что-то в этом мире не понимаете.

[Strannik223]

Опять все кроме Евгения шагают не в ногу

[vc]

Hi there,

... в реальности есть ещё приоритеты, который профессионал должен уметь правильно расставить....

Поэтому я не ругаюсь, а объясняю. В данном случае, правильно расставленные приоритеты - это и есть в первую очередь отказ от CGI, а потом уже все остальное.
И если Вы с этим не согласны, то значит или, у Вас есть тайные мотивы, или Вы что-то в этом мире не понимаете.

I've not detected any hidden agenda or misunderstanding in Tengiz' suggestions. The only sane approach to solving the performance problem would be finding out where the bottleneck is and _then_ fixing it. Pushing buttons and turning knobs randomly will hardly solve the problem. There is no scientific evidence that CGI is a bottleneck and until there is why give it up ?

VC

[vc]

Постраюсь запустить лог опять.

Hi,

I apologize that, due to my being too far, geographically, from the 'problem site', I cannot help much. I could, if you do not mind, take a look at the performance logs taken during a poor performance spell and see if I can find out anything.


Regards.

VC

[Privet]

....
Кстати, еще один ресурс, что юзают процессы - это канал.
Вот интересно, что получится, если они пытаются пропихнуть по нему больше, чем может пролезть.
Там в логе наверное должно быть - сколько в канал лезет?

Во время блокировки по каналу не передаётся почти НИЧЕГО.

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

Количество PHP потоков, а, следовательно и расход памяти не уменьшиться при переходе с CGI на модуль. Соответственно, это вряд ли решит вопрос. За исключения варианта, о котором пишет f_evgeny (съедание ресурсов при запуске CGI). Если бы это было так, то мы имели бы всплеск CPU близо или равно 100% и не было бы такого расхода памяти. Мы же имеем Idle почти 100% и availablе memory 0.

Мы имеем на прицеле второй сервер. Он может решить проблему, т.к. пожирание ресурсов PHP не будет тё тормозить, т.е. не будет эффекта положительной обратной связи.

SQL сервер, думаю, не разумно ставить на том же сервере, что и веб-сервер. tengiz, поправьте меня, если я не прав.

[Palych]

За исключения варианта, о котором пишет f_evgeny (съедание ресурсов при запуске CGI). Если бы это было так, то мы имели бы всплеск CPU близо или равно 100% и не было бы такого расхода памяти. Мы же имеем Idle почти 100% и availablе memory 0.

Мне кажется на создание процесса нужно больше памяти чем на thread... Впрочем у меня в етой области познания близкие к нулевым...