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

f_evgeny · Post by **f_evgeny** » 02 May 2004 20:50

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

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

f_evgeny · Post by **f_evgeny** » 02 May 2004 21:03

tengiz wrote:
f_evgeny wrote:А зачем таблица без индекса? У веба есть своя специфика. Скажем, если за 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 · Post by vc » 02 May 2004 21:14

f_evgeny wrote:Ну для чтения таблица не блокируется, если я правильно понимаю, вот из мануала:
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 · Post by **tengiz** » 02 May 2004 21:31

f_evgeny wrote:Ну для чтения таблица не блокируется, если я правильно понимаю, вот из мануала:
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 · Post by **vovap** » 02 May 2004 22:13

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

A. Fig Lee · Post by **A. Fig Lee** » 02 May 2004 23:28

Вообще я согласен с евгением. Вы вот ту все пытаетесь научно обосновать что MySQL здесь работать не может, в тоже время форумы с 50-кратной етому форуму нагрузкой работают успешно.
2. IIS задезайнен для тредов, CGI для него - екстремальная ситуация.

tengiz · Post by **tengiz** » 03 May 2004 00:21

A. Fig Lee wrote:Вообще я согласен с евгением. Вы вот ту все пытаетесь научно обосновать что MySQL здесь работать не может, в тоже время форумы с 50-кратной етому форуму нагрузкой работают успешно.

A. Fig Lee - ну какое же это научное возражение, если даже неизвестно какой конкретно storage engine используется на том форуме с типа 50-кратной нагрузкой? Для MySQL ведь есть и InnoDB, а также и SapDB. Кроме того, мы не знаем, что там за железка. Но что мы знаем точно, это что на Привете используется наихудший из возможных вариантов - MyISAM. Судя по доступной информации из их же документации (и, по всей видимости, по реальной жизни тоже) - компонента очень слабо приспособленна под хоть какие-то нагрузки.

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

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

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

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

tengiz · Post by **tengiz** » 03 May 2004 00:28

Privet, vovap

кстати, а какие действительно есть опасения по поводу хотя бы временного переключения на Apache/PHP? Если PHP код форума сделан правильно, то никаких лишних движений ведь делать не нужно, кроме как короткой последовательности чисто административных действий, которы описал f_evgeny? Ну, кроме, разумеется, одного, но серьёзного опасения по поводу грамотной поддержки со стороны уважаемого сообщества. Я не могу сказать, что был бы твёрдо уверен, что глядя на то, какую поддержку до сих пор удалось получить по MySQL, можно смело надеяться, что уж по Apache/PHP мы можем надёжно расчитывать на заметно более профессиональное отношение.

vovap · Post by **vovap** » 03 May 2004 02:17

tengiz wrote:Privet, vovap

кстати, а какие действительно есть опасения по поводу хотя бы временного переключения на Apache/PHP?

Да в целом никаких, оно и работало на Apache на параллельно вроде без замечаний. Но у Борися есть там еще что-то на NET - а оно привязано к IIS.
Вот он выше и расспрашивал - как дежать два сервера на одном IP.

Я не могу сказать, что был бы твёрдо уверен, что глядя на то, какую поддержку до сих пор удалось получить по MySQL, можно смело надеяться, что уж по Apache/PHP мы можем надёжно расчитывать на заметно более профессиональное отношение.

Вот как раз с Apache проблемм гораздо меньше - это легко видеть по тому, как быстро удалось найтилюдей для его конфигурации. Apache знают профессионально - все-таки самый используемый WEB сервер. А вот с MySQL - проблемма.

A. Fig Lee · Post by **A. Fig Lee** » 03 May 2004 02:17

Ну хорошо, щас пойду спрошу.

Post by **Privet** » 03 May 2004 02:21

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

Мне посоветовали, как логинить длинные запросы, но пока это не работает.

log_slow_queries=/var/log/slow-queries.log
long_query_time=2

ТТак же есть информация здесь http://dev.mysql.com/doc/mysql/en/Slow_query_log.html

vovap · Post by **vovap** » 03 May 2004 02:26

tengiz wrote:Почему-то среди тех, кто отметился на этих 12 страницах не оказалось никого, кто бы мог сказать, что он достаточно хорошо знает MySQL и поэтому может быстро разобраться с проблемой.

Именно это я имею в виду.

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

Именно поэтому я и пихаю SQL server.

Palych · Post by **Palych** » 03 May 2004 02:41

IMHO лучший способ обеспечить мирное сосуществование IIS и Apache - URL rewriting.
e.g. обьяснить IIS чтобы все запросы на privet.com/forum/.... он отвечал redirectом на privet.com:1333/forum/...

Или наоборот...

A. Fig Lee · Post by **A. Fig Lee** » 03 May 2004 02:46

vovap wrote:
tengiz wrote:Почему-то среди тех, кто отметился на этих 12 страницах не оказалось никого, кто бы мог сказать, что он достаточно хорошо знает MySQL и поэтому может быстро разобраться с проблемой.

Именно это я имею в виду.

Well, ну с моей точки зрения не понятно, что MySQL 100% виновата.
2. Ну трудна.. Может архитектуру подправить, чем костыли отдельному компоненту прикручивать.

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

Именно поэтому я и пихаю SQL server.

Дык кто ж возражает. Я - за. Ет лист будем знать кого и какую компанию винить. :mrgreen:

Если Привет хочет Виндовс - почему не MS SQL. не понимаю.

Palych · Post by **Palych** » 03 May 2004 02:46

vovap wrote:
tengiz wrote:Почему-то среди тех, кто отметился на этих 12 страницах не оказалось никого, кто бы мог сказать, что он достаточно хорошо знает MySQL и поэтому может быстро разобраться с проблемой.

Именно это я имею в виду.

Relax guys! This is fun!
Мы все постепенно становимся экспертами в MySQL...

A. Fig Lee · Post by **A. Fig Lee** » 03 May 2004 02:49

Palych wrote:IMHO лучший способ обеспечить мирное сосуществование IIS и Apache - URL rewriting.
e.g. обьяснить IIS чтобы все запросы на privet.com/forum/.... он отвечал redirectом на privet.com:1333/forum/...

Или наоборот...

a smysl?
тот же цги, только хуже. Вообще, IIS i CGI - етоп крайняк. Там же все на тредах.
Ето ж не апач.
IIS-u ISAPI dll - то, что нужно.

Palych · Post by **Palych** » 03 May 2004 03:16

A. Fig Lee wrote:
Palych wrote:IMHO лучший способ обеспечить мирное сосуществование IIS и Apache - URL rewriting.
e.g. обьяснить IIS чтобы все запросы на privet.com/forum/.... он отвечал redirectом на privet.com:1333/forum/...

Или наоборот...

a smysl?
тот же цги, только хуже. Вообще, IIS i CGI - етоп крайняк. Там же все на тредах.
Ето ж не апач.
IIS-u ISAPI dll - то, что нужно.

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

KVA · Post by **KVA** » 03 May 2004 03:19

Palych · Post by **Palych** » 03 May 2004 04:19

Похоже я сделал это!

10 threads, каждый выполняющий последовательность запросов соответствующую viewtopic.php повесили MySQL!
Причем ни память ни процессоры ни память не были загружены. Просто встал колом пока я не остановил клиента. После этого прошло несколько застрявших запросов и сервер возобновил нормальную работу.
К сожалению это не соответствует patternу, наблюдаемому на привете, но приближает к глубокомысленному и научно обоснованному выводу:
MySQL SUXXX!!! :mrgreen:

По крайней мере MyISAM.
Завтра попробую то же на линуксе и/или Mac OS, но вряд ли это что-то изменит...

Картина после рассасывания (должно было выполнится 10000 раз):

Code: Select all

View Topic1    13    38798  0    72464  53.85%   10.7/min
View Topic2    6      11780  61  70251  16.67%   5.0/min
View Topic3    5      14466  60  72034  20.00%   4.1/min
View Topic4    4      73         51        90  0.00%   2.2/sec
View Topic5    4      57         40        70  0.00%   2.2/sec
View Topic6    4      18093  40  72224  25.00%   3.3/min
View Topic7    6      61         50        80  0.00%   4.3/sec
View Topic8    2      55         40      70  0.00%   2.7/sec
TOTAL            44     16381   0   72464  22.73%   36.3/min

Test plan прилагается (это XML)

Post by **Privet** » 03 May 2004 04:27

На чём Вы пробовали? На WIndows? Можно счетчики сравнить?

Palych · Post by **Palych** » 03 May 2004 04:54

Privet wrote:На чём Вы пробовали? На WIndows? Можно счетчики сравнить?

Windows 2000 SP4.
Счетчики ставить не умею.... Завтра посмотрю...

f_evgeny · Post by **f_evgeny** » 03 May 2004 05:58

A. Fig Lee wrote:
Palych wrote:IMHO лучший способ обеспечить мирное сосуществование IIS и Apache - URL rewriting.
e.g. обьяснить IIS чтобы все запросы на privet.com/forum/.... он отвечал redirectом на privet.com:1333/forum/...

Или наоборот...

a smysl?
тот же цги, только хуже. Вообще, IIS i CGI - етоп крайняк. Там же все на тредах.
Ето ж не апач.
IIS-u ISAPI dll - то, что нужно.

Апач 2.xx тоже на тредах, видимо специально для Виндовс. Мы тут уже обсуждали, что модуль ISAPI PHP для IIS не рекомендуется, ввиду неотработанности, а так, это конечно было бы идеальным решением.

Post by **Privet** » 03 May 2004 08:19

f_evgeny wrote:...
Второй совет будет - поставить на UNIX, скорее всего Линукс, или FreeBSD, есть такое народное поверье, что веб-сервер с PHP надо ставить на UNIX. Поскольку на UNIX здесь похоже аллергия, я и не упоминаю даже. Но с CGI-то все ясно.
...

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

CGI оказалось на сервере относительно случайно. Мы только перешли с Perl на PHP и PHP на то время был сыроватым продуктом. Я понял документацию так, что ISAPI версия подоспеет буквально через пару недель-месяцев. Улучшение скорости по сравнению с Perl тогда было значительное и меня не особенно волновало некоторая некорректность с CGI. Увы, решение вопроса с ISAPI несколько затанулось и теперь объём и трафик форума заставляют искать другие решения, что мы и делаем. Я сейчас делаю новый сервер. Надеюсь, он нам поможет. Что на него ставить вопрос пока открытый. Пока известно, что на нём будет стоять база данных. Какая база и на чем пока я не знаю. У меня есть некоторые причины отказываться от MySQL. Администрацие её оставляет желать лучшего. За несколько лет пользовательский интерфейс застыл на одном месте и улучшения не предвидится. С MS SQL я работал практически. Он мне понравился ясностью и удобством пользовательского интерфейса. Смешно сказать, наша проблема всего лишь в том, что мы не можем посмотреть какие запросы создают проблемы. Посмотреть, наверно можно, но мы все пока не знаем как. Кнопки, на которую надо ткнуть, нет. Надо читать доки и выискивать команды, которые могут подойти.
Переходить на MS SQL тоже пока страшновато. Это многочасовая работа по переносу данных, которая неизвестно чем закончится.

Что касается UNIX, то пока у нас нет надёжной информации о том, как UNIX будет выглядетьпо сравнению с W2K. Поверья, естественно в счет не идут. Нам хотелось бы покороче и в цифрах.

A. Fig Lee · Post by **A. Fig Lee** » 03 May 2004 10:55

Palych wrote:приближает к глубокомысленному и научно обоснованному выводу:
MySQL SUXXX!!!

2001:
MySQL at Yahoo! :pain1:

Some Technical Details:
Operating system used: FreeBSD and Linux, synchronized using MySQL Replication
Size of database: 25 GB
Average number of concurrent connections: 60
Max number of concurrent connections: 250

A. Fig Lee · Post by **A. Fig Lee** » 03 May 2004 11:01

может просто перед каждым обращением к MySQL file lock добавить? Не самое ли простое решение? Или не решение?