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

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

[f_evgeny]

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

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

[f_evgeny]

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

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

Ну для чтения таблица не блокируется, если я правильно понимаю, вот из мануала:

Code: Select all

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 other threads that want to access this particular table will wait until the update is ready.

[vc]

Ну для чтения таблица не блокируется, если я правильно понимаю, вот из мануала:

Code: Select all

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 other threads that want to access this particular table will wait until the update is ready.

It appears that you do not undestand what's going on in this situation.

1. Session A runs a select for, say, 15 seconds

2. Session B tries to insert into the table that Session A is selecting from. It's blocked because it's unable to obtain an exclusive lock on the table.

3. All subsequent selects are blocked as well by Session B's insert which has not even started yet. The table is effectively unavailable for any kind of operation until Session A completes.

Pls. see the reference in one of my previous messages if you do not trust the quote.

VC

[tengiz]

Ну для чтения таблица не блокируется, если я правильно понимаю, вот из мануала:

Code: Select all

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 other threads that want to access this particular table will wait until the update is ready.

Мануал не врёт, но Вы не поняли его правильно:

1. для чтения из таблицы на таблицу всегда накладывается блокировка на чтение, которая не отпускается, пока чтение не закончится.

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

3. тут приходит третий поток, и тоже хочеть прочитать таблицу, для чего ему нужно получить блокировку на чтение.

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

В результате - блокировка на чтение в первом потоке и наличие ожидания блокировки на запись во втором потоку фактически блокирует все последующие чтения из таблицы.

<added> Ну вот, vc меня опять опередил </added>

[vovap]

Ну короче говоря нам нужно что-то для широкого логгинга состояния MySQL.
Для SQL server у нас такая процедура была - она гнала в файлы с заданным интервалом почти все, что можно выжать из него в смысле состояния. Лист процессов, блокировок и т.д.
Объем логов был колосальный, но именно так мы нашли мерзавца в конце концов. Если совместить это с имеющимся перформенс логом - вероятно можно будет разобраться что к чему.