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

[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, то можно было бы попытаться понять что же на самом деле происходило.