myhand, можно и поискать, но вы не получите заключения от независимых экспертов конкретно о себе.
Допустим, вы бы запостили точно такой же текст. Это баг ведь не является ничьей ошибкой. Поэтому его за 3 года не исправили и наверное уже не исправят. Тут разницы между Not a bug и verified нет. Verified - менее обидно для клиента. В данном случае сидеть ждать исправления - это самое настоящее лоховство.
или просто подумайте что происходит в обычной программе в случае когда результата очередного выполненного select-запроса в кеше нет, кеш разделен между несколькими потоками и блокировка одна единственная на весь это кеш.
myhand: Нет. Не при каждом. Все-таки вы даже первый комментарий к блогу не прочитали, как я просил.
И вам не советую читать эти блоги чтобы знать как работает кеш в mysql. У вас неправильное мнение сложилось теперь.
myhand: Вот это и является реальной проблемой: *некоторые* типы нагрузки. А вовсе не многопроцессорность.
До распространения многоядерных процессоров эти типы нагрузки и не думали даже масштабировать. Но с появлением современных средств, оказалось нужно масштабировать.
myhand: Но я за тех, кто сперва попробует и померяет.
ну сколько можно по третьему разу? да, нужно мерять. но если просят общих советов и их есть у нас.
myhand, мне кажется вы недооцениваете частоту блокировки кеша на запись. Он блокируется не только при update. кеш блокируется на запись при каждом НОВОМ запросе SELECT, который в кеше не нашелся. Нужно поместить в этот кеш результат работы запроса (байтики). При этом читать из кеша не может ни один параллельный процесс и, как следствие, падает масштабируемость. Дополнительные ядра не загружаются и обращая производительность падает. При некоторых типах нагрузки (если запросы разнообразны) это может происходить очень часто.
В последнее время многопроцессорные системы стали доступны большинству. Кеш в mysql был неплохой уникальной фичей и сыграл большую роль в вебе, но сейчас уже не следует думать, что его обязательно нужно включать всегда. Товарищи, которые сделали шуточную экспертную систему по одной из моих ссылок, именно это имели ввиду.
Об этом в блоге оракла только лишь намекнули in addition. Основная мысль про чистку кеша при update, но это само собой понятно.
myhand: Т.е. в принципе, вы понимаете что это не буквальное руководство к действию для дебилов, реагирующих на упоминание в тексте числительных. Именно то, о чем написал я: не трогай, не померив.
Обычно измерить что-то это целая проблема. Люди как раз и приходят сюда за подобными советами о best practices. Ну такой уж тут контингент.
Не можете обобщить опыт - лучше молчите. А я считаю, что могу и советую.
myhand: Уберите активное письмо - уйдут и локи.
В абзаце ровно одна мысль, как и положено абзацу. Упоминание о локах - попутное, "вдобавок". Эта проблема явно связана с тем, что там обсуждается, начиная с первого предложения (The issue here was that ...).
Но там описаны два явления.
Важность второго описанного в абзаце явления в ограничении масштабирования даже больше чем первого, поскольку "письмо" чаще возникает чем вы думаете. Оно даже возникает в конце каждого нового запроса SELECT. Не только во время UPDATE. Поэтому я акцентировал внимание на нем и выбрал его для цитирования.
myhand: Sizes in tens of megabytes are usually beneficial. Sizes in the hundreds of megabytes might not be.
я перевожу это так:
Размеры в десятки мегабайт, как правило, выгодны. Размеры в сотни мегабайт могут не быть [выгодными].
Вы снова подсократили "перевод". Кстати, как и предыдущую цитату:
Ну зачем захламлять сообщение левым текстом. Так людям сложнее увидеть как вы пытаетесь найти глупые оправдания.
В абзаце две мысли
The issue here was that the customer had a moderate level of write traffic, and the current query cache implementation invalidates all result sets for a given table whenever that table is updated. As the query cache grows in size, the number of entries that must be invalidated for a given table may grow as well.
и вторая, подтверждающая то, о чем я пишу.
In addition, the coarse locking on the cache can lead to lock contention that can kill performance, particularly on multi-core hardware.
myhand: Уменьшать с 200Mb до 60Mb - в данном случае замена шило на мыло. Абсолютно бессмысленная без измерений и последующего анализа.
Но в точности по советам в официальной документации. ничего авторитетнее документации быть не может по определению. ТС хотел общих и аргументированных советов - вот, пожалуйста.
myhand: Комментарии посмотри. Самый первый как раз про это. Для справки: в Debian stable сейчас 5.1.49.
смотрю
Prior to MySQL 5.1.33 a query that used SQL_NO_CACHE would still check the query cache to see whether the result is there
перевожу :
до версии 5.1.33 если запрос использовал SQL_NO_CACHE, результат [в кеше же хранится именно результат] все равно проверялся.
Про остальные случаи, где SQL_NO_CACHE отсутствует в запросе, не написано ничего.
Да и при чем тут комментарии, если в самом блоге в точности подтверждают мои слова.
Столкнулся с такой проблемой перейдя на MySQL 5.5.8, до этого был 5.1.x:
периодически множество запросов подвисает со статусом Waiting for query cache lock, запросы абсолютно разные и к разным таблицам. При это замечал, что в этот момент отрабатывают тяжелые запросы на кроне (2-3 секунды на запрос если не появляется Waiting for query cache lock), при это если запросы начинают виснуть со статусом Waiting for query cache lock, то скорость выполнения всех запросов уменьшается в разы... иногда вместо 2-3 сек становится минута и более...
да забыл сказать все таблицы в MyISAM, под кэш выделено 2 гига, база вся 7 гиг, на серваке ща 16 гиг оперативы...
специально выделил важное. в этой ситуации проблемы дизайна query_cache становятся особенно заметны. другие никак не связанные запросы могут тормозиться именно кешем, хотя без него все выполнялось бы параллельно. При большом кеше это становится особенно заметно, но и при маленьком тоже полностью нельзя это явление исключать.
---------- Добавлено в 18:27 ---------- Предыдущее сообщение было в 17:34 ----------
myhand, можно и поискать, но вы не получите заключения от независимых экспертов конкретно о себе.
Допустим, вы бы запостили точно такой же текст. Это баг ведь не является ничьей ошибкой. Поэтому его за 3 года не исправили и наверное уже не исправят. Тут разницы между Not a bug и verified нет. Verified - менее обидно для клиента. В данном случае сидеть ждать исправления - это самое настоящее лоховство.
А почему она *должна быть* одна-единственная?
там все максимально просто сделано. более сложный кеш будет тормозить. он и так уже себя ведет при очистке не ахти как.
в постгресе так вообще нет кеша результатов запросов и им норм.
Неужели только мне это кажется багом.
о, это просто узнать : описываете свое видение проблемы на bugs.mysql.com и получаете статус "вы - лох" (not a bug ).
myhand, исходники читайте.
или просто подумайте что происходит в обычной программе в случае когда результата очередного выполненного select-запроса в кеше нет, кеш разделен между несколькими потоками и блокировка одна единственная на весь это кеш.
Нет. Не при каждом. Все-таки вы даже первый комментарий к блогу не прочитали, как я просил.
И вам не советую читать эти блоги чтобы знать как работает кеш в mysql. У вас неправильное мнение сложилось теперь.
Вот это и является реальной проблемой: *некоторые* типы нагрузки. А вовсе не многопроцессорность.
До распространения многоядерных процессоров эти типы нагрузки и не думали даже масштабировать. Но с появлением современных средств, оказалось нужно масштабировать.
Но я за тех, кто сперва попробует и померяет.
ну сколько можно по третьему разу? да, нужно мерять. но если просят общих советов и их есть у нас.
myhand, мне кажется вы недооцениваете частоту блокировки кеша на запись. Он блокируется не только при update. кеш блокируется на запись при каждом НОВОМ запросе SELECT, который в кеше не нашелся. Нужно поместить в этот кеш результат работы запроса (байтики). При этом читать из кеша не может ни один параллельный процесс и, как следствие, падает масштабируемость. Дополнительные ядра не загружаются и обращая производительность падает. При некоторых типах нагрузки (если запросы разнообразны) это может происходить очень часто.
В последнее время многопроцессорные системы стали доступны большинству. Кеш в mysql был неплохой уникальной фичей и сыграл большую роль в вебе, но сейчас уже не следует думать, что его обязательно нужно включать всегда. Товарищи, которые сделали шуточную экспертную систему по одной из моих ссылок, именно это имели ввиду.
Об этом в блоге оракла только лишь намекнули in addition. Основная мысль про чистку кеша при update, но это само собой понятно.
Вы телепат и знаете что я думаю?
И что же пишется?
Байтики пишутся.
Раз вы этого не знаете, то точно можно понять каких процессах вы не думаете.
Подумайте, перечитайте еще раз все источники и приходите.
Т.е. в принципе, вы понимаете что это не буквальное руководство к действию для дебилов, реагирующих на упоминание в тексте числительных. Именно то, о чем написал я: не трогай, не померив.
Обычно измерить что-то это целая проблема. Люди как раз и приходят сюда за подобными советами о best practices. Ну такой уж тут контингент.
Не можете обобщить опыт - лучше молчите. А я считаю, что могу и советую.
Уберите активное письмо - уйдут и локи.
В абзаце ровно одна мысль, как и положено абзацу. Упоминание о локах - попутное, "вдобавок". Эта проблема явно связана с тем, что там обсуждается, начиная с первого предложения (The issue here was that ...).
Но там описаны два явления.
Важность второго описанного в абзаце явления в ограничении масштабирования даже больше чем первого, поскольку "письмо" чаще возникает чем вы думаете. Оно даже возникает в конце каждого нового запроса SELECT. Не только во время UPDATE. Поэтому я акцентировал внимание на нем и выбрал его для цитирования.
Sizes in tens of megabytes are usually beneficial. Sizes in the hundreds of megabytes might not be.
я перевожу это так:
Размеры в десятки мегабайт, как правило, выгодны. Размеры в сотни мегабайт могут не быть [выгодными].
Ну зачем захламлять сообщение левым текстом. Так людям сложнее увидеть как вы пытаетесь найти глупые оправдания.
В абзаце две мысли
и вторая, подтверждающая то, о чем я пишу.
Уменьшать с 200Mb до 60Mb - в данном случае замена шило на мыло. Абсолютно бессмысленная без измерений и последующего анализа.
Но в точности по советам в официальной документации. ничего авторитетнее документации быть не может по определению. ТС хотел общих и аргументированных советов - вот, пожалуйста.
Комментарии посмотри. Самый первый как раз про это. Для справки: в Debian stable сейчас 5.1.49.
смотрю
перевожу :
до версии 5.1.33 если запрос использовал SQL_NO_CACHE, результат [в кеше же хранится именно результат] все равно проверялся.
Про остальные случаи, где SQL_NO_CACHE отсутствует в запросе, не написано ничего.
Да и при чем тут комментарии, если в самом блоге в точности подтверждают мои слова.
myhand, ну какой же ты нудный.
вот, продиагностируй удаленно . версия 5.5.8, без "бага".
не самая типичная ситуация для хостинга с вечным недостатком памяти, но она встречается у людей с более разнообразным опытом чем у тебя
http://www.sql.ru/forum/actualthread.aspx?bid=6&tid=822926&pg=1
периодически множество запросов подвисает со статусом Waiting for query cache lock, запросы абсолютно разные и к разным таблицам. При это замечал, что в этот момент отрабатывают тяжелые запросы на кроне (2-3 секунды на запрос если не появляется Waiting for query cache lock), при это если запросы начинают виснуть со статусом Waiting for query cache lock, то скорость выполнения всех запросов уменьшается в разы... иногда вместо 2-3 сек становится минута и более...
да забыл сказать все таблицы в MyISAM, под кэш выделено 2 гига, база вся 7 гиг, на серваке ща 16 гиг оперативы...
специально выделил важное. в этой ситуации проблемы дизайна query_cache становятся особенно заметны. другие никак не связанные запросы могут тормозиться именно кешем, хотя без него все выполнялось бы параллельно. При большом кеше это становится особенно заметно, но и при маленьком тоже полностью нельзя это явление исключать.
---------- Добавлено в 18:27 ---------- Предыдущее сообщение было в 17:34 ----------
и по своей же ссылке немного не дочитал
http://blogs.oracle.com/dlutz/entry/mysql_query_cache_sizing