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

[Palych]

Tengiz,
А как можно искусственно вызвать конвой на не очень большой базе?

[tengiz]

А как можно искусственно вызвать конвой на не очень большой базе?

Это не зависит от размера базы - это зависит от количества активных задач (которых должно быть намного больше, чем доступных процессоров) и от того, как спроектирована система. На DB2 или SQL Server, к примеру, этого добиться вряд ли возможно, так как специальные анти-конвойные меры заложены во изначальный дизайн. Т.е. оставляя в стороне баги реализации (который всегда есть), на этих СУБД конвои невозможны. Для того, чтобы специально вызвать конвой в MySQL нужно хотя бы примерно представлять архитектуру этой системы, найти компонет (или компоненты), где не принято необходимых защитных мер, и после этого прицельно лупить именно туда, написав специализированный стресс-тест.

Вот ссылка на приветовские дискуссии, где мы подробно обсуждали что такое конвой, когда он возникает, и что нужно делать, чтобы его избежать:

совсем новая: http://forum.privet.com/viewtopic.php?t=50915
двухлетней давности: http://forum.privet.com/viewtopic.php?t=22926

[tengiz]

vovap, Privet - я же говорил, что у меня есть этическая проблема. Вернее, проблема-то не у меня, а проблема с тем, что обязательно начнутся подобные базары. На всякий случай, если Вы не очень внимательно следили за дискуссией - вторая цитата - ответ на первую. Даже после того, как прошёл десяток страниц бесплодных перетираний темы у уважаемых коллег есть сомнения в том, не наличествуют ли здесь тайные мотивы. Поэтому я хоть и не отказываюсь от своих предложений активной помощи, но настоятельно призываю всех приложить максимум усилий для того, чтобы тщательно разобраться в проблеме и только потом принимать какие-либо решения.

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

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

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

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

[YellowMan]

tengiz, Вы же понимаете что это несерьезно
Единственным определяющим фактором в этой ситуации может быть только то захотите ли Вы сами помочь к каждой конкретной ситуации или нет, а не надпись на форуме что у кого-то есть какие-то подозрения. Я не верю что люди сумевшие пережить подростковую гормональную бурю могут всерьез воспринимать такие аргументы...
К сожалению как мы видим пресловутое open-source общество совершенно не в состоянии оказать реальную помощь в данной конкретной ситуации.И наверное даже не потому что нет желания - просто исчерпаны возможности продукта бесплатно написанного программистами для программистов в свободное от работы время.

[Siberian Cableman]

Да уж напонимает "Лошадью ходи, лошадью" (c)

[tengiz]

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

Судя по логам система вполне адекватна типичной средней нагрузке, даже имеется вполне солидный запас. Дисковая подсистема вообще практически всё время отдыхает. Но разнесение СУБД и веб сервера по разным машинам разумеется не помешает. При условии, что PHP код форума позволяет это сделать без дополнительных усилий.

[vovap]

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

Дорогой tengiz,
этическая поблемма у Вас будет, если Вам будут платить деньги. На сей счет вы можете быть совершенно спокойны.
Я не знаю, готов ли Борис предоставить Вам питание на время проведения работ, но думаю, что на этическую проблемму это не потянет, даже если добавить алкогольные напитки.

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

Дорогой tengiz, я боюсь, что наши возможности по дальнейшему выяснению близки к исчерпанию. К кому именно Вы обращаетесь? Лично я на англоязычные форумы не пойду - языками не владею. Борису и так хватает, сейчас еще и установка нового сервера. Конфигурация у нас не типовая - pHp и MySQL на Windows. Может, конечно, кто-нибудь из участников займется толком и раскопает, но опыт говорит о другом. Скорее всего, через пару дней энтузиазм пройдет, топик закроется и на сем все кончится. Так уже не раз было. Именно поэтому мне кажется целесообразным потавить базу, которая в наших условиях более управляема.

[Siberian Cableman]

Лично я на англоязычные форумы не пойду - языками не владею.

А как же Вы работаете в Штатах ?

[vovap]

А как же Вы работаете в Штатах ?

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

[Strannik223]

Да причем тут возможности Open source community?
Для того что бы общатся на эту тему надо подробно знать что и как происходит, добавлять какую то отладку, вобщем быть на месте.
Ну спрошу я "у нас форум тормозит, что делать", кроме того что мы сами толком не знаем какая компонента тормозит.
Что бы спросить продуктивно надо хорошую домашнюю работу сделать.
Желание разобратся есть, а вот путей я что то не очень вижу.
Проблему можно воспроизвести?

[tengiz]

vovap,

Если я за это получу деньги, то это уже будет не этическая проблема, а нарушение моего трудового соглашения с моим работодателем в части касающейся moonlighting. Так что моя этическая проблема только в одном - как бы не получилось, что кто-то посчитает, а затем и по-доброму сообщит куда следует, что мы тут допускаем недобросовестную конкуренцию и чисто монопольное выкручивание рук пользователям, вынуждая их работать с продуктами, для которых есть аналоги сопоставимого или лучшего качества или исподтишка поддалкивая их к такому решению. И чисто теоретическая возможность оказаться объектом разбирательств по поводу нарушения кодекса business conduct, который мы все подписываем и который предписывает быть предельно аккуратными с настоящими или потенциальными пользователями, как бы чего не вышло, мне не кажется привлекательной. Каким бы абсурдом это не казалось.

[Strannik223]

У меня следующий вопрос.
Насколько легко получить наблюдаемый эффект?

Далее, я вижу единственный "научный" метод в расстановке вывода отладочной информации, потому что в такой динамичной системе что то другое вряд ли будет работать.

Например логировать все запросы. Включая время начала и окончания.
Далее. Дают ли счетчики CPU точное время когда это приключилось? Если да, то по есть некоторая вероятность что это будет случатся на чем то характерный запросах.

[tengiz]

1. Насколько легко получить наблюдаемый эффект?
2. Дают ли счетчики CPU точное время когда это приключилось?

1. Судя по тому, что проблемы с производительностью форума - обычное и регулярное явление, я погалаю, что воспроизводится это чётко.
2. Да, в perfmon логах есть абсолютная привязка по времени.

[vovap]

И чисто теоретическая возможность оказаться объектом разбирательств по поводу нарушения кодекса business conduct, который мы все подписываем и который предписывает быть предельно аккуратными с настоящими или потенциальными пользователями, как бы чего не вышло, мне не кажется привлекательной. Каким бы абсурдом это не казалось.

Ну уж если Вы хотите подойти с настолько формальной позиции - то ситуация такова: лицензия на SQL server у Бориса уже судя по всему есть. Второй продукт -фри. Так что о каких-либо закупках речь не идет ни сейчас ни в будущем. Наконец приоритет в предложении поставить SQL принадлежит (как обычно) мне - я уже давным давно писал, что было бы хорошо если нет проблемм с лицензией.
В этих словиях я не способен увидет перспективы никакого разбирательства, даже с утверждением, что сервер был втюхан с рекламными целями.
В качестве альтернативы я бы предложил Борису продажу футболок с Вашей аватрой и ником - для поправки финансового положения сайта.

(Кстати, как неосторожно Вы предлагали Борису WIN 2003, а?
да и бог с Вами - Ваше участие -то не обязательно и отнюдь не является решающим фактором - в том-то и суть, что спецов по SQL хватает.)

[vovap]

1. Судя по тому, что проблемы с производительностью форума - обычное и регулярное явление, я погалаю, что воспроизводится это чётко.

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

[vc]

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

Hi,

First, I'd try to determine the general system health using perfmon. As you know,
essentially there are three major resources: CPU, memory and IO. In perfmon, I'd select the following metrics:

a. for the systemas a whole:

%User time
%Privileged time
%Idle time

Memory available bytes
Memory pages/sec

Physical disk:
% Disk Time
% Idle Time

b. for the mysql process:

%User time
%Privileged time
%Idle time

Working set

====

Analyzing the data can lead to two conclusions: either there is simply not enough resources to satisfy so many requests or mysql is experiencing some blocking problems.

Secondly, using PHP log files as other posters suggested, you can determine where a long-running request spends its time -- is it i waiting for the query to complete or elsewhere. Also, there is a very useful PHP db access interface our PHP developers are using (I am not familiar very much with it myself) to connect to Oracle. It also supports mysql, postgress, etc. One imporatnt feature of the package is that it allows to see how much time a specific SQL statement spends in the database and you can obtain its execution plan. The package name is ADOdb 4.22 ( http://php.weblogs.com/adodb ).

Thirdly, there are some performance counters in mysql itself which may be of help. Pls. see http://www.mysql.com/news-and-events/ne ... 00301.html .

I understand that it's not easy to capture/reproduce the problem but you can collect performance information using perfmon/adodb/mysqladmin into logfiles and analyze them post factum. As I said before, I can take a look at those files.

Regards.

VC

[Privet]

Я хотел бы заметить, что тот вид блокировки сервера, о котором мы говорим, не является единственным. Мне кажется, мы немного зациклились на нём и забываем, что сервер не так часто заклинивает полностью, зато часто время ответа составляет несколько десятков секунд. Возможно, это прелюдия к полному заклиниванию. Процентов на 80 я уверен, что это именно так.

Воспроизвести это и просто и сложно. Например, некоторые административные команды (например, если я ищу IP) клинят сервер достаточно надёжно, но всё-таки не всегда. При небольшой нагрузке и на некоторых данных запрос пролетает в секунду. При нагрузке (в дневное время) тот же запрос висит 20-30 секунд. Для разных IP - разное время.
Такое воспроизведение клина не является достаточно корректным и не очень интересно для нас.

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

P.S. Вы можете запросить доступ в раздел Технической поддержки если:

1. Вы являетесь профессионалом в соответствующих компьютерных и/или сетевых технологиях и имеете достаточный практический опыт.
2. Вы готовы оказывать техническую поддержку форуму.

Это временный раздел и членство в нём предоставляется только на время решения какого-то вопроса.

P.S.2. Пожалуйста, ни в коем случае не проводите никаких экспериментов на рабочем сервере. Это будет рассматриваться как DOS атака.

[A. Fig Lee]

Так если MS SQL сервер есть - че мучится?

[vovap]

Так если MS SQL сервер есть - че мучится?

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

[A. Fig Lee]

Так если MS SQL сервер есть - че мучится?

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

Мой поинт - если оставлять MySQL, то надо на УНИХ его пихать. Ну на костылях он на Виндовс, я уж молчу про Апача. О будущим надо думать, чтоб потом не было мучитейьно больно.

[vovap]

О будущим надо думать, чтоб потом не было мучитейьно больно.

Женитесь.

[YellowMan]

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


ЗЫ А что такое moonlighting ? Моих зачаточных знаний английского хватает только на то чтобы вспомнить что это американизм обозначающий самогон или процесс его приготовления

[tengiz]

ЗЫ А что такое moonlighting ? Моих зачаточных знаний английского хватает только на то чтобы вспомнить что это американизм обозначающий самогон или процесс его приготовления

Самый лучший известный мне перевод (хоть и вряд ли литературный), точно отражающий суть - халтурка. Т.е. дополнительный приработок.

[tengiz]

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

vovap - разумеется, перспективы нет, но на то, чтобы в этом разобраться понадобится время, в течение которого будешь чувствовать себя верблюдом. А мне не хочется опять оказаться в анекдоте про то, где в конце концов "серебро-то нашлось, а осадок остался". У меня уже был сходный опыт - всё в конце концов разъяснилось и вполне благополучно разрешилось, но несколько неприятных дней было и у меня, и у связанных со мной людей.

Кстати, как неосторожно Вы предлагали Борису WIN 2003, а?

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

[tengiz]

First, I'd try to determine the general system health using perfmon. As you know, essentially there are three major resources: CPU, memory and IO. In perfmon, I'd select the following metrics:...

vc, как я уже выше писал, в логах, которые я видел, самый интересный отрезок времени показал два сильно отличающихся случая аномального поведения. См. приложенный screenshot.

Показанные там счётчики (Available MBytes жёлтый график, Processes - синий, CPU% для процесса MySQL - красный, context switches/sec - зелёный) - наиболее интересные. Всё остальное менее информативно: IO практически idle - длина очереди не превышает одного-двух запросов, за исключением первого аномального участка, где длина очереди была в среднем между 3 и 4 запроса ввода/вывода, а также был очень кототкий всплеск, когда в очереди был 7 запросов; CPU% для веб-сервера в пределах 5%, total CPU% в пределах 40-70%. Поэтому я их убрал с картинки чтобы её не загромождать.

Оба участка, когда Available MBytes (жёлтый) резко падает, сопровождались увеличенным количеством активных процессов (синий), большинство из которых - PHP. Как я уже писал, первый случай - где MySQL CPU% (красный) падает почти до нуля, похож на аномально долгое выполнение запроса СУБД, что всех постепенно заблокировало - отсюда и много запущенных PHP, которые никак не могут завершиться, при этом IO крайне неэффективен, так как в основном делается в среднем около 200 коротких (около 4K) запросов ввода/вывода в секунду (< 1 MB/sec). Либо это похоже на дедлок, прерванный таймаутом.

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

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