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

[Privet]

Как поменять scale отдельно для каждого счётчика в performance мониторе?

[tengiz]

Как поменять scale отдельно для каждого счётчика в performance мониторе?

[Palych]

Я тут позапускал запросы, наблюдая поведение MySQL.
Это правильно что следующий запрос накладывает 3 Table_lockа?

Code: Select all

SELECT u.username, u.user_id, u.user_posts, u.user_from, u.user_website, u.user_email, u.user_icq, u.user_aim, u.user_yim, u.user_regdate, u.user_msnm, u.user_viewemail, u.user_rank, u.user_sig, u.user_sig_bbcode_uid, u.user_avatar, u.user_avatar_type, u.user_allowavatar, u.user_allowsmile, p.*,  pt.post_text, pt.post_subject, pt.bbcode_uid
    FROM phpbb_posts p, phpbb_users u, phpbb_posts_text pt    
WHERE p.topic_id = ${TopicID} 
             AND pt.post_id = p.post_id
       AND u.user_id = p.poster_id
    ORDER BY p.post_time ASC
    LIMIT 0, 15 

Борис, может попробовать понаблюдать за Table_locks_waited во время замедления форума? И сравнить его динамику с "расслабленным" периодом?

[Palych]

Я тут наваял quick'n'dirty hack чтобы длинные запросы в лог отбрасывать. Может попробовать?

[vc]

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

OK, I would say that the memory exhaustion cause is precisely the rapid increase in number of PHP processes which cannot complete probably because of the database not finishing SQL requests quickly enough. We can safely exclude the CPU as the bottleneck -- it varies at about 15-20% if I am reading the graph correctly. It would be nice to confirm the assumption about the DB being a problem by getting timing data for SQL statements. Do you know what kind of DB access library the system uses ? In my previous posting I mentioned an ADODB debug module for PHP which produces both timing data and explain plans for SQL requests. If the system does not use the library, would it be possible to try it in order to obtain this kind of information ? The information would be extremely useful in any case, even if a decision is made to switch to an alternative database, as it's the only way to judge how efficient the DB is.

I do not think memory is a bottleneck either but I am not quite sure because its unclear a) what units the graph uses (Available bytes) b) what the workset for mysql is; c) what the workset for each PHP process is; d) how many PHP processes were running; was the number 30 and then it went up to 92 ? d) how heavy the paging was. I'd like to exclude the situation where the DB just does not have enough memory to sustain the load -- I imagine it needs some memory for the db block cache, etc.

Regarding locking, here's what the manual ( http://atlassw1.phy.bnl.gov/doc/mysql/M ... mance.html ) has to say:
<quote>
The table locking code in MySQL is deadlock free.

MySQL uses table locking (sic !) (instead of row locking or column locking) to achieve a very high lock speed. For large tables, table locking is MUCH better than row locking, but there are of course some pitfalls.

Table locking enables many threads to read from a table at the same time, but if a thread wants to write to a table, it must first get exclusive access. During the update all others threads that want to access this particular table will wait until the update is ready.

As updates of databases normally are considered to be more important than SELECT, all statements that update a table have higher priority than statements that retrieve information from a table. This should ensure that updates are not 'starved' because one issues a lot of heavy queries against a specific table.

One main problem with this is the following:

A client issues a SELECT that takes a long time to run.
Another client then issues an INSERT on a used table; This client will wait until the SELECT is finished..
Another client issues another SELECT statement on the same table; As INSERT has higher priority than SELECT, this SELECT will wait for the INSERT to finish. It will also wait for the first SELECT to finish!
</quote>

So, to sum up, I am inclined to think that the primary cause is some locking situation in the DB accompanied by a probable convoy effect (secondary cause). Again, in order to further diagnose the issue, we need timing information on the SQL requests during such a period of performance degradation. The information is critical with any database; it would prevent a frustrating situation when a lot of work would have been spent on the switch to another db and the problem would still be there...

Also, sometimes, it's useful to have both perfmon raw numbers (report) and the graph because due to scaling some information may be overlooked.

Regards.

VC

[vc]

Tengiz,

It would appear that the situation with forum performance degradation (judging by the permon graphs) is as simple as described in the mysql manual itself, namely a combination of a select in one session and a subsequent write attempt to the same table from another session effectively serializes access to the table for the duration of such select. It would be nice, of course, to confirm the assumption by SQL traces.

A natural solution to the problem would be to use a database having row-level locks. There are two options here:

1. Convert the mysql ISAM tables to InnoDB tables that do have row-level locks;
2. Switch to an alternative database with row-level locks.

Both options would require probably the same amount of time/labor.

Regards.

VC

[vc]

[quote="Palych"]Я тут позапускал запросы, наблюдая поведение MySQL.
Это правильно что следующий запрос накладывает 3 Table_lockа?

Code: Select all

SELECT u.username, u.user_id, u.user_posts, u.user_from, u.user_website, u.user_email, u.user_icq, u.user_aim, u.user_yim, u.user_regdate, u.user_msnm, u.user_viewemail, u.user_rank, u.user_sig, u.user_sig_bbcode_uid, u.user_avatar, u.user_avatar_type, u.user_allowavatar, u.user_allowsmile, p.*,  pt.post_text, pt.post_subject, pt.bbcode_uid
    FROM phpbb_posts p, phpbb_users u, phpbb_posts_text pt    
WHERE p.topic_id = ${TopicID} 
             AND pt.post_id = p.post_id
       AND u.user_id = p.poster_id
    ORDER BY p.post_time ASC
    LIMIT 0, 15 

According to the mysql manual, yes, it's expected behaviour. Please see my other messages on the subject.

VC

[f_evgeny]

Hi there,

... в реальности есть ещё приоритеты, который профессионал должен уметь правильно расставить....

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

I've not detected any hidden agenda or misunderstanding in Tengiz' suggestions. The only sane approach to solving the performance problem would be finding out where the bottleneck is and _then_ fixing it. Pushing buttons and turning knobs randomly will hardly solve the problem. There is no scientific evidence that CGI is a bottleneck and until there is why give it up ?

VC

1. Видите ли, можно пойти на любой форум, где народ работает с вебом, PHP или Перлом и спросить в чем проблема. И ответ будет такой:
в первую очередь надо отказаться от CGI, в случае Apache посоветуют mod_php, mod_perl, или FastCGI.
И до этого даже разговаривать никто не будет.
Второй совет будет - поставить на UNIX, скорее всего Линукс, или FreeBSD, есть такое народное поверье, что веб-сервер с PHP надо ставить на UNIX. Поскольку на UNIX здесь похоже аллергия, я и не упоминаю даже. Но с CGI-то все ясно.

2. На phpBB2/MySQL работают достаточно большие форумы, например http://ian.gaiaonline.com/forum/index.php, сейчас там:

Code: Select all

Who is Online - In total there are 6491 users online :: 5003 Registered, 304 Hidden and 1184 Guests

We have 551793 registered users
Our forums have a total of 65677890 articles

Они там говорят о количестве постов, порядка 50 000 в день. Сюда, кстати уже постили ссылку на статью администратора этого форума о модификации phpBB для больших нагрузок.
Поэтому я не думаю, что проблема именно в базе. Возможно можно посмотреть настройки, в тренде, посвященном настройке phpBB2

3. Насчет мотивов я написал (и не отказываюсь от своих слов), потому, что ситуация мне совершенно непонятна.
Сейчас установлен IIS, запускающий CGI, т.е. на каждый запрос стартует и завершается отдельное приложение. Весь интернет полон FAQ-ов о том, что переход к модулю это первый шаг при арботе по повышению производительности вебсервера. Установлен, сконфигурирован и проверен Apacht с PHP подключенным в виде модуля. Осталось только выключить IIS и переключить переключить Apache на 80-й порт. Это ничем не угрожает и запутать ситуацию не может, испытания не связаны с финансовыми затратами, или возможностью повреждения оборудования но мы их не проводим, а лезем во внутренности базы. Хотя обе вещи можно делать параллельно. Значит есть какие-то мотивы, которых я не знаю. Обычное дело. Ничего обидного. Я конечно понимаю, что если люди разбираются в базах, то они туда и смотрят. Но почему бы и не побробовать совет из FAQ-ов?

[tengiz]

Do you know what kind of DB access library the system uses?...

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

I do not think memory is a bottleneck either but I am not quite sure because its unclear a) what units the graph uses (Available bytes) b) what the workset for mysql is; c) what the workset for each PHP process is; d) how many PHP processes were running; was the number 30 and then it went up to 92 ? d) how heavy the paging was. I'd like to exclude the situation where the DB just does not have enough memory to sustain the load -- I imagine it needs some memory for the db block cache, etc.

vc, на картинке показано Available MBytes, масштабы каждого счётчика должны быть чётко видны, поэтому для всех графиков есть абсолютная привязка. Большинство других счётчиков малоинформативно, так как их динамика практически никак не коррелирует с показанными на выложенной картинке. Подкачка умеренная, менялась в течение всего лога незначительно, включая два участка замедления. Увеличение количества процессов - это исключительно PHP, но так как непосредственного счётчика экземпляров одного процесса в perfom нет, то такой вывод делается по косвенным, но вполне очевидным признакам. Показать на статичной картинке это сложно, так как приходится постоянно переключаться между различными связанными счётчиками, количество которых непригодно для одновременного показа на графике. Что касается памяти для MySQL - к сожалению в первом логе этой информации нет. Однако по остутствию заметной подкачки можно сделать вывод, что либо памяти ему хватает, либо MySQL умеет эффективно с этим справляться.

MySQL uses table locking (sic !) (instead of row locking or column locking) to achieve a very high lock speed. For large tables, table locking is MUCH better than row locking, but there are of course some pitfalls.

Вообще-то это не совсем так. Табличная блокировка vs строчная/страничная имеет преимущество, когда нужно просканировать большую таблицу целиком и строчных блокировок может понадобиться очень много. Или наоборот, таблица настолько маленькая, что гранулярность наложенной табличной блокировки ненамного хуже строчных/страничных. Зато при этом не будет тратиться время на лишние вызовы менеджера блокировок - два вызова lock/release на таблицу или количество строк в таблице lock/release строчных блокировок. Ну и самое главное преимущество табличной блокировки - это просто в реализации, что очень важно для таких "народных" проектов. Но когда нужно прочитать 5% строк из таблицы размером 1 GB, табличная блокировка намного хуже любой другой. Тем более, когда есть индекс.

[vc]

MySQL uses table locking (sic !) (instead of row locking or column locking) to achieve a very high lock speed. For large tables, table locking is MUCH better than row locking, but there are of course some pitfalls.

Вообще-то это не совсем так. Табличная блокировка vs строчная/страничная имеет преимущество, когда нужно просканировать большую таблицу целиком и строчных блокировок может понадобиться очень много. Или наоборот, таблица настолько маленькая, что гранулярность наложенной табличной блокировки ненамного хуже строчных/страничных. Зато при этом не будет тратиться время на лишние вызовы менеджера блокировок - два вызова lock/release на таблицу или количество строк в таблице lock/release строчных блокировок. Ну и самое главное преимущество табличной блокировки - это просто в реализации, что очень важно для таких "народных" проектов. Но когда нужно прочитать 5% строк из таблицы размером 1 GB, табличная блокировка намного хуже любой другой. Тем более, когда есть индекс.

I am afraid that you are preaching to the choir -- those are not my words but rather a quote from the mssql manual ;). I am actually amazed that the db works at all with a simplistic lock manager like that...

VC

[vc]

Hi there,

... в реальности есть ещё приоритеты, который профессионал должен уметь правильно расставить....

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

I've not detected any hidden agenda or misunderstanding in Tengiz' suggestions. The only sane approach to solving the performance problem would be finding out where the bottleneck is and _then_ fixing it. Pushing buttons and turning knobs randomly will hardly solve the problem. There is no scientific evidence that CGI is a bottleneck and until there is why give it up ?

VC

1. Видите ли, можно пойти на любой форум, где народ работает с вебом, PHP или Перлом и спросить в чем проблема. И ответ будет такой:
в первую очередь надо отказаться от CGI, в случае Apache посоветуют mod_php, mod_perl, или FastCGI.
И до этого даже разговаривать никто не будет.
Второй совет будет - поставить на UNIX, скорее всего Линукс, или FreeBSD, есть такое народное поверье, что веб-сервер с PHP надо ставить на UNIX. Поскольку на UNIX здесь похоже аллергия, я и не упоминаю даже. Но с CGI-то все ясно.

2. На phpBB2/MySQL работают достаточно большие форумы, например http://ian.gaiaonline.com/forum/index.php, сейчас там:

Code: Select all

Who is Online - In total there are 6491 users online :: 5003 Registered, 304 Hidden and 1184 Guests

We have 551793 registered users
Our forums have a total of 65677890 articles

Они там говорят о количестве постов, порядка 50 000 в день. Сюда, кстати уже постили ссылку на статью администратора этого форума о модификации phpBB для больших нагрузок.
Поэтому я не думаю, что проблема именно в базе. Возможно можно посмотреть настройки, в тренде, посвященном настройке phpBB2

3. Насчет мотивов я написал (и не отказываюсь от своих слов), потому, что ситуация мне совершенно непонятна.
Сейчас установлен IIS, запускающий CGI, т.е. на каждый запрос стартует и завершается отдельное приложение. Весь интернет полон FAQ-ов о том, что переход к модулю это первый шаг при арботе по повышению производительности вебсервера. Установлен, сконфигурирован и проверен Apacht с PHP подключенным в виде модуля. Осталось только выключить IIS и переключить переключить Apache на 80-й порт. Это ничем не угрожает и запутать ситуацию не может, испытания не связаны с финансовыми затратами, или возможностью повреждения оборудования но мы их не проводим, а лезем во внутренности базы. Хотя обе вещи можно делать параллельно. Значит есть какие-то мотивы, которых я не знаю. Обычное дело. Ничего обидного. Я конечно понимаю, что если люди разбираются в базах, то они туда и смотрят. Но почему бы и не побробовать совет из FAQ-ов?

All the 'approaches' you've suggested above to solve the problem are not scientific but, I don't know, maybe religious , based on beliefs(1), hearsay (2) and rules-of-thumb (3).

A scientific way is to collect facts, analyze them and then make a decision as to what to do next. Looking at the facts we have now, there is just nothing to indicate that the problem is caused by some purported CGI deficiency. There is a strong indication reinforced by the mssql manual, though, to suggest that the database behaviour in this scenario is not adequate due to its (the database) locking mechanism whereby a long running select converts the db into a single user system.

VC

[f_evgeny]

Но когда нужно прочитать 5% строк из таблицы размером 1 GB, табличная блокировка намного хуже любой другой. Тем более, когда есть индекс.

Хочу обратить Ваше внимание, что в Вебе такие ситауции должны быть исключены, я имею в виду 5% из 1GB, или 50MB. А MySQL используется главным образом для Web.

[tengiz]

I am afraid that you are preaching to the choir -- those are not my words but rather a quote from the mssql manual .

VC,

My sincere apologies for this little misunderstanding - I should have used proper quote formatting and should have explicitly mentioned MySQL as the source of the quote.

[tengiz]

Хочу обратить Ваше внимание, что в Вебе такие ситауции должны быть исключены, я имею в виду 5% из 1GB, или 50MB. А MySQL используется главным образом для Web.

Я честно не понимаю, как веб позволяет исключить такие ситуации. Поясните, pls.

[f_evgeny]

A scientific way is to collect facts, analyze them and then make a decision as to what to do next. Looking at the facts we have now, there is just nothing to indicate that the problem is caused by some purported CGI deficiency. There is a strong indication reinforced by the mssql manual, though, to suggest that the database behaviour in this scenario is not adequate due to its (the database) locking mechanism whereby a long running select converts the db into a single user system.

VC

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