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

tengiz · Post by **tengiz** » 29 Apr 2004 19:44

Privet wrote:tengiz, Palych, я пока не столь категоричен...

А я ничего против CGI не имею. Смысл избавлять от CGI есть только тогда, когда эта модель действительно мешает. Но я не думаю, что у нас именно такой случай. Судя по логу, форум должен работать нормально 80% времени, 20% времени, когда есть проблема, резкое увеличине количества активных процессов скорее всего объясняется именно так, как Вы и говорите - один или несколько запросов к БД "залипают", вызывая лавинообразные последствия, которые потом довольно долго рассасываются. Если добавить памяти, ситуаци не улучшится - потому что вместо 60 "залипших" php мы получим 160 "залипших" php. Искать и устранять нужно причину.

В моменты "залипания" резко (примерно на два порядка) возрастает context switches/sec - но для того, чтобы разобраться почему это происходит, нужно больше информации.

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

У меня - никаких. Только если PHP/MySQL имеют что-то предложить: они умеет вести какой-нибудь лог активности? Можно из заставить профилировать запросы? Хоть какие-нибудь данные для сколько-нибудь обоснованного анализа эти продукты предлагают? Или нужно лезть в исходники и наобум втыкать printf???

tengiz · Post by **tengiz** » 29 Apr 2004 19:52

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

Что это за индекс и почему он так долго копируется/строится? На самом деле действительно что-то смутно припоминаю, но никаких деталей. Если хотите в offline можем на эту тему поговорить. Есть вполне стандартные варианты, позволяющие сильно оптимизировать массовые одноразовые загрузки данных, массовые одноразовые построения индексов и пр.

Post by **Privet** » 29 Apr 2004 20:06

tengiz, индексом я назвал таблицу, которая содержит поисковый индех. Это не индекс в понятии баз данных. Есть отдельный скрипт, который эту таблицу может заново насчитать вместо копирования.

Проблема в том, что для импорта 2 гиг базы, очевидно, нужно время. Большую часть времени занимает копирование (импортирование) этой таблицы. Время копирования можно значительно сократить, если индексную таблицу не копировать, но тогда её надо заново насчитывать, т.к. если её копировать после активации форума, то она не будет соответствовать данным.

tengiz · Post by **tengiz** » 29 Apr 2004 20:18

Privet wrote:Проблема в том, что для импорта 2 гиг базы, очевидно, нужно время. Большую часть времени занимает копирование (импортирование) этой таблицы. Время копирования можно значительно сократить, если индексную таблицу не копировать, но тогда её надо заново насчитывать, т.к. если её копировать после активации форума, то она не будет соответствовать данным.

На такое количество данных (< 10 G) на современной системе вряд ли должно уходить больше пары часов включая импорт и построение всех индексов, если использовать специально для этого предназначенные возможности, встроенные в ядро СУБД (bulk load, optimized b-tree population, etc).

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

Post by **Privet** » 29 Apr 2004 20:26

tengiz, я с удовольствием. Вообще, можно было бы на новый сервер сразу MS SQL установить, но у меня пока с ним проблемы.

tengiz · Post by **tengiz** » 29 Apr 2004 20:33

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

Я посмотрел реальный лог - проблем с запуском процесса лог не показывает. Проблема долгого выполнения PHP процесса - вот что на самом деле является главной головной болью. Процессор, причём, совершенно не в зашкале. В зашкале при этом память. В результате имеем заметную подкачку и другие неприятные последствия. Если бы запуск CGI при этом осуществлялся хоть в тысячу раз быстрее, это ровным счётом бы ничего не изменило. А источник проблемы, как уже было сказано, скорее всего MySQL, который периодически вдруг отказывается нормально работать. Именно в этом и нужно разбираться. Есть признаки, что MySQL уходит в глухой конвой. А это уже радиакально не лечится - если СУБД специально не спроектирована, чтобы их избегать, она рано или поздно на них наткнётся. Или нужно жёстко ограничивать количество параллельных запросов: конвой - это проблема масштабируемости по количеству одновременно выполняемых задач, пытающихся достучаться одного или нескольких суперпопулярных ресурсов.

Post by **Privet** » 29 Apr 2004 21:34

Кстати, у меня используются таблицы типа MyISAM (не InnoDB)

vovap · Post by **vovap** » 30 Apr 2004 00:37

tengiz wrote:На такое количество данных (< 10 G) на современной системе вряд ли должно уходить больше пары часов включая импорт и построение всех индексов, если использовать специально для этого предназначенные возможности, встроенные в ядро СУБД (bulk load, optimized b-tree population, etc).

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

Мне представляется, что это было бы лптимальное решений. Я вот хотел высказать несколько очередным мудрых мыслей по поводу MySQL - но ясно, что все равно никто толком не ответит. Импорт такого объема не должен представлять проблемму.
Так что, дорогой Борис, берите tengiz пока он согласен - и ставьте SQL Server на новый. Заодно получим еще одно преимущество - прекратятся разговоры "переставьте все на Unix" :lol:

tengiz · Post by **tengiz** » 30 Apr 2004 00:46

tengiz wrote:
f_evgeny wrote:... На мой взгляд, можно сделать вывод, что при работе на K-6-600 в конфигурации CGI значительная часть времени процессора уйдет на запуск CGI.
Я посмотрел реальный лог - проблем с запуском процесса лог не показывает. Проблема долгого выполнения PHP процесса - вот что на самом деле является главной головной болью.... А источник проблемы, как уже было сказано, скорее всего MySQL, который периодически вдруг отказывается нормально работать.

Ещё пара комментариев - конвой, разумеется, может случиться не только в СУБД. Любая многопользовательская система где есть необходимость часто (много раз за квант) и ненадолго брать и отпускать разделяемый ресурс может испытывать такую проблему. Так что в зависимости от того насколько аккуратно написан компонент, это может быть и сам PHP, а также библиотека клиентского доступа к MySQL в случае, когда клиенты и MySQL находятся на одной машине.

tengiz · Post by **tengiz** » 30 Apr 2004 00:54

vovap wrote:Мне представляется, что это было бы лптимальное решений. Я вот хотел высказать несколько очередным мудрых мыслей по поводу MySQL - но ясно, что все равно никто толком не ответит.

Я бы всё-таки сначала убедился, что проблема действительно внутри или вокруг СУБД. Иначе, в случае если что-то криво в PHP мы ничего толком не исправим. Возможно, слегка сгладим ситуацию, но по мере роста нагрузки можем опять в неё упереться. Да и потом, мне по понятным соображениям сильно агитировать за SQL Server не совсем этично

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

vovap · Post by **vovap** » 30 Apr 2004 02:11

Не отлынивайте :lol:

tengiz wrote:Я бы всё-таки сначала убедился, что проблема действительно внутри или вокруг СУБД.

Ну вы же смотрели логи. Памято-то кто сожрал?

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

Это есть определяющий фактор. Я неоднократно об этом говорил. Вот, скажем, Вы как дальше собираетесь разбираться? Не знаете? И никто не знает. Потому как надо по-хорошему выяснять - а что делает MySQL в это время. А как выяснить сие - никто толком сказать не может. Если он тормозит - то почему - из-за конвоя, распростроненнх блокировок или просто деградации под нагрузкой с комулятивным эффектом в борьбе за ресурсы в PHP? Спросить я могу, а кто ответит?
Поэтому SQL Server лучше уже тем, что его знают. Полно народу тут с ним професионально работает. Наш лучший спец в нем вообще живет рядом. Чего еще желать?

Strannik223 · Post by **Strannik223** » 30 Apr 2004 02:24

А в списке рассылки по MySQL никто не пробовал спрашивать?

tengiz · Post by **tengiz** » 30 Apr 2004 02:39

vovap wrote:Ну вы же смотрели логи. Памято-то кто сожрал?

Память "сожрали" PHP процессы, которых оказалось больше, чем обычно. Видимо просто потому, что они резко замедлились, а темп поступления запросов не снизился, поэтому апач их и поназапускал пока хватило памяти. Почему PHP замедлились - ещё предстоит выяснить. Если дело в самом PHP, а не в MySQL, то переход на SQL Server не очень сильно здесь поможет.

vovap · Post by **vovap** » 30 Apr 2004 03:05

tengiz wrote:Почему PHP замедлились - ещё предстоит выяснить.

Как?
Я вообще не вижу как PHP мог бы затормозится сам по себе - разве что ограничен пул коннектов и они кончились. Другие варианты затрудняюсь представить. Единственный ресурс что они юзают - база данных.Так как все в независимых процессах - то и влияния взаимного нет. Во всех WEB приложениях что я имел дело (а это все-таки моя профессия) скорость определялась именно взаимодействием с базой. А главное еще раз - ну дальше-то, что делать? Как разбираться?
Да, то не апач, то IIS. Говорю же, запутали всех эти умельци

tengiz · Post by **tengiz** » 30 Apr 2004 03:58

vovap wrote:Как?

Это, я так понимаю, риторический вопрос? Я, разумеется, не знаю как, так как никогда PHP в глаза не видел, в его потрохах не ковырялся. Нужно брать за жабры членов Привета, которые работают системными администраторами на UNIX/Linux и пр., а также в полный рост воспользоваться преимуществами OpenSource и искать товарищеской взаимопомощи у соответствующего сообщества. Так что тут - я пас.

Я вообще не вижу как PHP мог бы затормозится сам по себе - разве что ограничен пул коннектов и они кончились. Другие варианты затрудняюсь представить. Единственный ресурс что они юзают - база данных.Так как все в независимых процессах - то и влияния взаимного нет.

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

Первое серьёзное "залипание" сопровождалось падением %CPU практически до нуля, что похоже на недетектируемый дедлок, "рассосавшийся" по таймауту. Второе серьёзное "залипание" имеет совершенно другой характер - MySQL продолжает продолждает "сжигать" CPU, но при этом резко (почти на два порядка) подскакивает общее количество переключений контекста, что очень похоже на конвой. Но конвой, в отличие от дедлока, может "рассосаться" сам.

Следить за счётчиками собственно PHP очень сложно, так как эти процессы постоянно рождаются и умирают, а у perfmon есть проблема с журналированием таких ситуаций. В "нормальном" состоянии количество активных PHP процессов находится в пределах десятка. В моменты "залипания" их количество подскакивает почти до 70.

А во втором логе ничего необычного нет - всё стабильно и красиво. Никаких "залипаний". Для дальнейшего анализа нужно больше данных - новые логи.

katit · Post by **katit** » 30 Apr 2004 04:59

Короче это глупо так рассуждать.
Надо ставить SQL Server и все. Тогда будет точно известно что и как.
И если база то выяснится просто. И т.к. SQL Server умельцев достаточно то и если проблема там - то решим. :umnik1:

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

f_evgeny · Post by **f_evgeny** » 30 Apr 2004 05:58

katit wrote:Короче это глупо так рассуждать.
Надо ставить SQL Server и все. Тогда будет точно известно что и как.
И если база то выяснится просто. И т.к. SQL Server умельцев достаточно то и если проблема там - то решим.

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

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

Post by **Privet** » 30 Apr 2004 06:08

К сожаленю, сегодня я только что пришел. Завтра, боюсь будет опять так.

Post by **Privet** » 30 Apr 2004 06:10

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

Strannik223 · Post by **Strannik223** » 30 Apr 2004 06:19

Кое какая информация о особенностях блокировок MySQL.
http://dev.mysql.com/doc/mysql/en/Locking_Issues.html

Тенгиз, судя по тому что Борис сказал что тип базы не InnoDB, и по фразе из доки

Except for InnoDB and BDB storage engines, all locking in MySQL is deadlock-free for storage engines that use table-level locking. This include the MyISAM, MEMORY (HEAP), and ISAM engines. Deadlock avoidance is managed by always requesting all needed locks at once at the beginning of a query and always locking the tables in the same order

это не должен быть дедлок базы.
Я так понял что всюду table-lock используется.
Просто из любопытства, интересно что будет если перевести в InnoDB, там строчная блокировка, может полегчает?
Или BDB, там страничная.
[/quote]

f_evgeny · Post by **f_evgeny** » 30 Apr 2004 06:40

Strannik223 wrote:Кое какая информация о особенностях блокировок MySQL.
http://dev.mysql.com/doc/mysql/en/Locking_Issues.html

Тенгиз, судя по тому что Борис сказал что тип базы не InnoDB, и по фразе из доки
Except for InnoDB and BDB storage engines, all locking in MySQL is deadlock-free for storage engines that use table-level locking. This include the MyISAM, MEMORY (HEAP), and ISAM engines. Deadlock avoidance is managed by always requesting all needed locks at once at the beginning of a query and always locking the tables in the same order

это не должен быть дедлок базы.
Я так понял что всюду table-lock используется.
Просто из любопытства, интересно что будет если перевести в InnoDB, там строчная блокировка, может полегчает?
Или BDB, там страничная.

[/quote]
Я вот тоже про дидлоки на MySQL не слыхал, особенно учитывая, что лочатся таблицы и что транзакций нет (До последнего времени не было).

f_evgeny · Post by **f_evgeny** » 30 Apr 2004 06:47

vovap wrote:Это есть определяющий фактор. Я неоднократно об этом говорил. Вот, скажем, Вы как дальше собираетесь разбираться? Не знаете? И никто не знает. Потому как надо по-хорошему выяснять - а что делает MySQL в это время.

Проблема вовсе не обязательно в MySQL. На сегодня ясно одно - в архитектуре есть одно очень неэффективное место - CGI. Вообще, это АЗБУКА, что с CGI нормальной производительности быть не может. Причем заменить CGI модули очень легко. С этого и надо начинать.

tengiz · Post by **tengiz** » 30 Apr 2004 07:07

Strannik223 wrote:Тенгиз, судя по тому что Борис сказал что тип базы не InnoDB, и по фразе из доки ...<skipped>... это не должен быть дедлок базы. Я так понял что всюду table-lock используется. Просто из любопытства, интересно что будет если перевести в InnoDB, там строчная блокировка, может полегчает?

Процитированная фраза, во-первых, довольно туманна - откуда engine знает, какую таблицу я захочу выбрать в следующем запросе в моей транзакции, чтобы её заблокировать в "правильном" порядке? Или в этих движках вообще нет поддержки для транзакций или других способов обеспечения атомарности, а также подзапросов и union? Во-вторых, дедлоки ведь могут случиться не только на блокировках, а на любых объектах, на которых нужно ждать. Неужели эти движки могут обходиться только блокировками? Это малореально, так как классическая блокировка - оносительно тяжеловесный объект и если можно обойтись спинлоком или латчем, то обычно так и делают. Использование блокировок для доступа к таблицам ещё понятно, но я сильно удивлюсь, если вся синхронизация в egnine сводится к исключительно табличным блокировкам. Как-то сложно прверить, что им им больше ни к чему не нужно синхронизиновать доступ.

Я бегло просмотрел кое-что из документации по MySQL и обнаружил, что там имеется замечательная команда LOCK TABLE. Я не понимаю, как при наличии доступной пользователю такой инструкции можно говорить о deadlock free engine?

Big Cheese · Post by **Big Cheese** » 30 Apr 2004 07:09

Strannik223 wrote:это не должен быть дедлок базы.
Я так понял что всюду table-lock используется.
Просто из любопытства, интересно что будет если перевести в InnoDB, там строчная блокировка, может полегчает?
Или BDB, там страничная.

В принципе coarse lock granularity вполне может быть причиной конвоя. Я, конечно, не эксперт в MySQL, но одно время лазил по исходникам - никаких механизмов борьбы с конвоем там вроде как нет. InnoDB, вполне возможно, хорошо спроектированная система, но MySQL (опять таки - могу ошибаться) использует только часть ее функциональности, причем достаточно базовые вещи. Насчет масштабируемости / производительности BDB под Windows у меня тоже большие сомнения

, глядя как они реализуют "семафоры" в менеджере блокировок на Win32 API... Опять же anti-convoy logic там не реализована, система управления пулом страниц в памяти мне показалась достаточно примитивной... Вобщем, я бы выбрал MS SQL, особенно учитывая помощь Тенгиза.

tengiz · Post by **tengiz** » 30 Apr 2004 07:18

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

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

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