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. Ну такой уж тут контингент.
Не можете обобщить опыт - лучше молчите. А я считаю, что могу и советую.
Но там описаны два явления.
Важность второго описанного в абзаце явления в ограничении масштабирования даже больше чем первого, поскольку "письмо" чаще возникает чем вы думаете. Оно даже возникает в конце каждого нового запроса SELECT. Не только во время UPDATE. Поэтому я акцентировал внимание на нем и выбрал его для цитирования.
я перевожу это так:
Размеры в десятки мегабайт, как правило, выгодны. Размеры в сотни мегабайт могут не быть [выгодными].
Ну зачем захламлять сообщение левым текстом. Так людям сложнее увидеть как вы пытаетесь найти глупые оправдания.
В абзаце две мысли
и вторая, подтверждающая то, о чем я пишу.
Но в точности по советам в официальной документации. ничего авторитетнее документации быть не может по определению. ТС хотел общих и аргументированных советов - вот, пожалуйста.
смотрю
перевожу :
до версии 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
специально выделил важное. в этой ситуации проблемы дизайна query_cache становятся особенно заметны. другие никак не связанные запросы могут тормозиться именно кешем, хотя без него все выполнялось бы параллельно. При большом кеше это становится особенно заметно, но и при маленьком тоже полностью нельзя это явление исключать. ---------- Добавлено в 18:27 ---------- Предыдущее сообщение было в 17:34 ---------- и по своей же ссылке немного не дочитал
http://blogs.oracle.com/dlutz/entry/mysql_query_cache_sizing
