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

tengiz · Post by **tengiz** » 28 Apr 2004 08:09

Privet wrote:Вряд ли. Deadlock никогда не рассасывается. Два процесса мёртво держат друг друга за глотку. Во всяком случае это моё понимание как программиста. Может быть, в терминах баз денных это означает иное. На форуме же перегрузка потихоньку по мере выполнения запросов рассасывается. Это хорошо видно в администраторе.

Это зависит от того, есть ли в MySQL автоматическое детектирование дедлоков - тут вроде у есть люди, имеющие реальный опыт работы с этим продуктом, для них это должно быть элементарным вопросом. Системы без такового обычно имеют таймаут, после чего дедлок через некоторое время разрешается сам собой. Но обычно дедлок не сопровождатется зашкалом CPU. И если же я правильно понял, что как раз именно это и имеет место быть. Тогда это может быть "convoy phenomena" - неприятное явление, хорошо известное в базах данных аж с начала 70-х и причиной которого является неаккуратное (хотя и функционально 100% правильное) программирование синхронизации доступа к очень активно используемому ресурсу. Все "главные" современные СУБД (MySQL excluded - ничего про него не знаю) этой проблемы не имеют, потому что заведомо проектируются так, чтобы её избежать.

<added>

Полез на сайт MySQL.com и нашёл, что если в качестве подсистемы хранинения и обработки транзакций использовать ещё одно финское техническо чудо - InnoDB (которое его автор лет 5 назад пытался поочерёдно продать Oracle, IBM и MS) - то MySQL действительно имет автоматическое разрешение дедлоков. Я уже много хорошего слышал про этот InnoDB, парень, который его делал видимо достаточно грамотен. Однако про конвои на их сайте нет ничего. Оно, конечно, может ровным счётом не означать, но тем не менее...

</added>

<added more>

After a little more googling...

Surely enough Heikki Tuuri - the guy who wrote the InnoDB Engine - is very well aware of the convoy problem and does know a fact or two about the internal mechanics of MS SQL Server, including the UMS - UserModeScheduler. However, аccording to the following, InnoDB doesn't appear to employ any real anti-convoy techniques, except some hard-coded threading-related limits:

http://www.distlab.dk/mysql-4.1/html/sr ... ource.html

Which makes me believe that the most popular storage engine that comes with MySQL and that is bound to be much simpler than more "advanced" InnoDB would hardly be convoy-aware at all.

</added more>

f_evgeny · Post by **f_evgeny** » 28 Apr 2004 19:10

Новости с фронтов?

Post by **Privet** » 29 Apr 2004 02:47

Palych wrote:
Privet wrote:Таблицы заблокированы...

Oni tochno zablokirovany, ili mysql prosto pozhiraet resursy?

Если верить winmysqladmin, то заблокированы (locked).

Я очень скромно оцениваю свои способности правильно интерпретировать информация от администратора. Любые советы где и что посмотреть принимаются.

Лог сегодня постараюсь посмотреть и выделить кризисные места.

Сервер собрал, но пока не заводится и издаёт ужсающий звук (зуммер).
Монитор в основном не заводится. Только два раза получил сообщение CMOS Error. Проверка RAM - ок. Unknown processor 2133.
В настройки войти не удалось.

Вчера скачал документацию, сегодня буду смотреть, проверять перемычки и пр.

Кто бы мне объяснил что такое unbuffered DDR и как её отличить от buffered?

SBolgov · Post by **SBolgov** » 29 Apr 2004 03:08

Privet wrote:Кто бы мне объяснил что такое unbuffered DDR и как её отличить от buffered?

Личного опыта, к сожалению, нет, но по информации с "железячных" сайтов:

На примитивном уровне: unbuffered - это "обычная", buffered или registered - для серверов. Не все чипсеты поддерживают работу с buffered модулями. (Ваш - AMD 762 - поддерживает.)

Судя по описанию Вашей материнки на сайте производителя, она поддерживает ТОЛЬКО registered модули.

Вот что мне удалось накопать в достаточно старом FAQ по компьютерной памяти ( http://www.ixbt.com/mainboard/memgloss.html ):

unbuffered

буферизованных

registered

buffered

ключей

key

Отсюда можно сделать вывод, что buffered и unbuffered DIMM отличаются расположением вырезов в нижней части модуля.

Кто знает лучше - поправьте меня, пожалуйста.

SBolgov · Post by **SBolgov** » 29 Apr 2004 03:33

SBolgov wrote:Судя по описанию Вашей материнки на сайте производителя, она поддерживает ТОЛЬКО registered модули.

Ой, вру. Похоже, "обычные" она тоже поддерживает, но "обычными" нельзя набить максимальный объём - 4ГБ.

Насколько я помню, "обычные" поддерживаются, но ими нельзя заполнить все 4 слота DIMM. Если хочется заполнить все 4, то все модули памяти должны быть registered.

К сожалению, точную ссылку найти пока не могу. :pain1:

SBolgov · Post by **SBolgov** » 29 Apr 2004 03:45

Вот, накопал статью о Registered DIMM. Рассказывает о SDRAM Registered DIMM и DDR SDRAM Registered DIMM. Судя по картинке - Registered DDR модули имеют один "вырез" внизу, а не два, как "обычные". И, естественно, есть различия в маркировке модулей.

См. в конце статьи последний абзац перед "Заключением":

m — тип используемого модуля памяти (R — Registered, U - Unbuffered)

Post by **Privet** » 29 Apr 2004 05:27

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

Первые сюрпризы (для меня) уже есть. Причина блокировки процессора - нехватка памяти. Пока я не могу сказать какой процесс (процессы) забирают памаять. Вполне возможно, что версия f_evgeny верна.

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

На памяти написано:

Наклейки:

Code: Select all

A4303293 MEMORY, DDR333
512MB                              2201
8N:X005202146         5000004332

Code: Select all

64X64      64X64dBOc8nAVA333
DDR333  12210010033031504ds

Чип:

AVANT
S80064YMTW - GX

Что бы это значило?

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

Я допускал несколько грубых ошибок в интерпретации счетчиков. Главный показатель памати я смотрел - comitted memory, что никогда не превышало критических значений. На самом деле оказалось, что Available memory в некоторых случаях близко к нулю.

Тем не менее считать, что проблема решена слишком рано. Я бы попросил высказаться профи.
Расход памяти нарастает очень быстро. Установка дополнительных модулей мало, что даст, да и некуда их ставить. Основной сервер имеет всего два слота, которые уже заняты (2х512).
Надо искать причину такого лавинообразного роста потребной памяти. Я запустил лог опять и дополнил счетчики Working Set на все процессы, чтобы посмотреть какие процессы требуют память.
tengiz, одобрямс?

Волчара · Post by **Волчара** » 29 Apr 2004 07:09

я и так могу сказать. Это апач 1.3 и его prefork model, когда запускается один child на каждые 10-100 запросов. Каждый чайлд кушает нехреново памяти

На винде апач надо скомпилировать с mpm_winnt, должно помочь. Только надо сначала проверить совместимость этого модуля с php

Для начала можно немного поиграться с конфигом prefork модуля, тоже поможет

А может на винде mpm стандартно идет... я никогда не читал подробно. В общем смотреть конфиг этих модулей

tengiz · Post by **tengiz** » 29 Apr 2004 08:12

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

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

Seryi · Post by **Seryi** » 29 Apr 2004 08:29

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

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

f_evgeny · Post by **f_evgeny** » 29 Apr 2004 08:57

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

YellowMan · Post by **YellowMan** » 29 Apr 2004 10:04

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

vovap · Post by **vovap** » 29 Apr 2004 12:10

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

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

vovap · Post by **vovap** » 29 Apr 2004 12:13

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

CGI.

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

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

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

f_evgeny · Post by **f_evgeny** » 29 Apr 2004 12:32

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

CGI.

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

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

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

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

Palych · Post by **Palych** » 29 Apr 2004 14:27

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!

Post by **Privet** » 29 Apr 2004 16:55

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

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

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

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

A. Fig Lee · Post by **A. Fig Lee** » 29 Apr 2004 17:05

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

Post by **Privet** » 29 Apr 2004 17:11

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

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

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

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

Post by **Privet** » 29 Apr 2004 17:15

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

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

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

Post by **Privet** » 29 Apr 2004 17:18

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

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

katit · Post by **katit** » 29 Apr 2004 18:16

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

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

f_evgeny · Post by **f_evgeny** » 29 Apr 2004 19:20

Давайте попытаемся рассчитать несколько цифр. Не помню, какой комп на привете, поэтому буду считать для компа, который я тестировал (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.