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

[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

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

[vc]

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.

No hay problema, amigo

[vovap]

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

Наоборот, это типовая ситуация - для WEB - чуть - чуть из много.

[tengiz]

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

f_evgeny, повышение производительности - это очень общее высказывание. Переход с CGI на не-CGI устраняет только определённый вид проблем. А именно, когда для запуска процесса не хватает CPU (что проявляется в стабильной загрузке процессора близко к 100%, причём значительная часть этих процентов должна приходиться на kernel time). Однако судя по логам скорее всего такой проблемы у форума пока нет. Во всяком случае по тем логам, которые были доступны. Если Вы хотите сказать, что не верите и что другими словами Вас откровенно вводят в заблуждение из каких-то тайных мотивов - запросите доступ к форуму тех поддержки, оттуда можно скачать логи и внимательно изучить из самому.

А скорость старта процессов более чем избыточна для типичной приветовской нагрузки - посмотрире на картинку, которую я прицепил пару сообщений назад - в тех самых двух неприятных случаях система с лёгкостю запустила 50+ CGI приложений в течение короткого времени, когда её к этому вынудили, могла бы запустить и больше, но только заткнулось всё на на нехватке памяти, а не нехватке CPU. Потому что запущенные процессы резко замедлили свою работу и не завершились достаточно быстро.

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

[f_evgeny]

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

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

Вы не можете через веб возвращать 50мб. Я не написаб, что веб исключает, об этом должен позаботиться разработчик.

[f_evgeny]

f_evgeny, повышение производительности - это очень общее высказывание. Переход с CGI на не-CGI устраняет только определённый вид проблем. А именно, когда для запуска процесса не хватает CPU (что проявляется в стабильной загрузке процессора близко к 100%, причём значительная часть этих процентов должна приходиться на kernel time). Однако судя по логам скорее всего такой проблемы у форума пока нет. Во всяком случае по тем логам, которые были доступны. Если Вы хотите сказать, что не верите и что другими словами Вас откровенно вводят в заблуждение из каких-то тайных мотивов - запросите доступ к форуму тех поддержки, оттуда можно скачать логи и внимательно изучить из самому.

А скорость старта процессов более чем избыточна для типичной приветовской нагрузки - посмотрире на картинку, которую я прицепил пару сообщений назад - в тех самых двух неприятных случаях система с лёгкостю запустила 50+ CGI приложений в течение короткого времени, когда её к этому вынудили, могла бы запустить и больше, но только заткнулось всё на на нехватке памяти, а не нехватке CPU. Потому что запущенные процессы резко замедлили свою работу и не завершились достаточно быстро.

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

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

[tengiz]

Вы не можете через веб возвращать 50мб. Я не написаб, что веб исключает, об этом должен позаботиться разработчик.

Боюсь, что Вы не поняли, что я сказал:

Во-первых, прочитать 5% таблицы и вернуть 5% таблицы клиенту - это разные вещи. Например, если у Вас есть индекс по дате, но нет индекса по дате и пользователю, то если в запросе сказано, что нужно выдать все сообщения пользователя X за дату Y, то СУБД прочитает все строки, где дата = Y, но клиенту вернёт только те, для которые ещё и пользователь = X.

Во вторых, если даже вместо 5% будет 0.0005%, т.е. 5К из 1GB, то это ещё хуже, так как для интересующегося 0.0005% данных блокировать всю таблицу, пока эти 0.0005% будут найдены вообще говоря странно.

Но даже если предположить, что такие запросы редкая экзотика, поэтому специально для них мы не будем строить и поддерживать актуальный индекс, говорить, что для больших таблиц табличные блокировки НАМНОГО (именно так, большими буквами) лучше - это чистое надувательство со стороны тех, кто публикует такую документацию.

[f_evgeny]

Боюсь, что Вы не поняли, что я сказал:

Во-первых, прочитать 5% таблицы и вернуть 5% таблицы клиенту - это разные вещи. Например, если у Вас есть индекс по дате, но нет индекса по дате и пользователю, то если в запросе сказано, что нужно выдать все сообщения пользователя X за дату Y, то СУБД прочитает все строки, где дата = Y, но клиенту вернёт только те, для которые ещё и пользователь = X.

Во вторых, если даже вместо 5% будет 0.0005%, т.е. 5К из 1GB, то это ещё хуже, так как для интересующегося 0.0005% данных блокировать всю таблицу, пока эти 0.0005% будут найдены вообще говоря странно.

Но даже если предположить, что такие запросы редкая экзотика, поэтому специально для них мы не будем строить и поддерживать актуальный индекс, говорить, что для больших таблиц табличные блокировки НАМНОГО (именно так, большими буквами) лучше - это чистое надувательство со стороны тех, кто публикует такую документацию.

А зачем таблица без индекса? У веба есть своя специфика. Скажем, если за 30с не нашли то, что надо, то дальше можно уже и не искать. Да и вообще на эту тему могу сказать одно. MySQL довольно успешно занимает определенную нишу, конкурентов фактически как бы и нет.

[tengiz]

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

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

А разве Вы где-то увидели, что я имею что-либо против внимательного анализа? Я просто не уверен, что первое что нужно делать для диагностики - это непременно пробовать что-то другое. Тем более, когда полученная конфигурация опять окажется "нестандартной". Это живой форум, хозяин которого не хочет зря рисковать. Даже с существущими проблемами форум худо-бедно работатет. Но никто не может гарантировать, что при переключении на любую другую альтернативую "нестандартную" конфигурацию не вылезут другие проблемы, из-за которых форум просто встанет на несколько дней. Поэтому я бы на его месте попробовал бы выжать максимум информации из того, что сейчас работает. Хотя бы затем, чтобы попытаться понять, в какую именно сторону нужно смотреть, чтобы сделать максимально эффективный и минимально рискованный "следственный эсперимент". Просто потому, у что Привета нет обслуживающего персонала 24x7x365, который по первой необходимости всё бросит и быстро починит поломку.

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

[tengiz]

А зачем таблица без индекса? У веба есть своя специфика. Скажем, если за 30с не нашли то, что надо, то дальше можно уже и не искать. Да и вообще на эту тему могу сказать одно. MySQL довольно успешно занимает определенную нишу, конкурентов фактически как бы и нет.

Не юлите и не меняйте тему на ходу . Даже 30 секундная блокировка целой таблицы для прочтения одной миллионной объёма таблицы - вынужденное решение, на которое авторы MyISAM или как он там называется пошли просто потому, что что-либо более сложное им оказалось не по зубам. Ведь не зря MySQL предлагает InnoDB и что-то ещё, что умеет значительно более сложные и эффективные вещи, чем просто блокирование таблиц целиком. Но писать в документации, что табличные блокировки НАМНОГО лучше, чем страничные/строчные? Как говорят в одном черноморском городе - пусть купят гуся и ему морочат голову.

[f_evgeny]

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

Ну на несколько дней, это Вы несколько преувеличиваете опасность. Это если что-нибудь внутри корпуса взорвется.
Переключить очень легко, так же, как и вернуться назад:
Туда:
- Переключение - преправить в hhtpd.conf порт с 1333 на 80
- Выключить IIS
- Нажать кнопочку апача "Restart"
Назад:
- Переключение - преправить в hhtpd.conf порт с 80 на 1333
- Нажать кнопочку апача "Restart"
- Включить IIS
Самое неприятное, что может быть, это падения Апача, но это не кирпич, при падении ничего не ломает.