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

[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, а потом уже все остальное.
И если Вы с этим не согласны, то значит или, у Вас есть тайные мотивы, или Вы что-то в этом мире не понимаете.