Тюнинг mysql

я перевожу это так:

Размеры в десятки мегабайт, как правило, выгодны. Размеры в сотни мегабайт могут не быть [выгодными].

Ну зачем захламлять сообщение левым текстом. Так людям сложнее увидеть как вы пытаетесь найти глупые оправдания.

В абзаце две мысли

и вторая, подтверждающая то, о чем я пишу.

Правильно (хотя я бы выбрал "полезны"). Но ключевое слово: "могут".

Т.е. в принципе, вы понимаете что это не буквальное руководство к действию для дебилов, реагирующих на упоминание в тексте числительных. Именно то, о чем написал я: не трогай, не померив.

В абзаце ровно одна мысль, как и положено абзацу. Упоминание о локах - попутное, "вдобавок". Эта проблема явно связана с тем, что там обсуждается, начиная с первого предложения (The issue here was that ...). Уберите активное письмо - уйдут и локи.

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

Обычно измерить что-то это целая проблема. Люди как раз и приходят сюда за подобными советами о best practices. Ну такой уж тут контингент.

Не можете обобщить опыт - лучше молчите. А я считаю, что могу и советую.

Но там описаны два явления.

Важность второго описанного в абзаце явления в ограничении масштабирования даже больше чем первого, поскольку "письмо" чаще возникает чем вы думаете. Оно даже возникает в конце каждого нового запроса SELECT. Не только во время UPDATE. Поэтому я акцентировал внимание на нем и выбрал его для цитирования.

Тогда не трогать - и дать сделать все людям умеющим.

Могу и сделал. Это вы полезли "опытом" меряться.

Вы телепат и знаете что я думаю? Нет там никакого второго и первого - проблема одна и та же: изменение большого объема информации *в кеше* при достаточно интенсивной записи.

И что же пишется?

Байтики пишутся.

Раз вы этого не знаете, то точно можно понять каких процессах вы не думаете.

Подумайте, перечитайте еще раз все источники и приходите.

Байтики много куда пишутся.

Я расцениваю это как то, что на конкретный заданный вопрос вы ответа не знаете.

Ну вот и поделитесь. А то читает мои мысли, понимаешь, без спросу - щас милицию позову!

И это пишет человек, осиливший перевод элементарной фразы из документации со второй попытки?

myhand, мне кажется вы недооцениваете частоту блокировки кеша на запись. Он блокируется не только при update. кеш блокируется на запись при каждом НОВОМ запросе SELECT, который в кеше не нашелся. Нужно поместить в этот кеш результат работы запроса (байтики). При этом читать из кеша не может ни один параллельный процесс и, как следствие, падает масштабируемость. Дополнительные ядра не загружаются и обращая производительность падает. При некоторых типах нагрузки (если запросы разнообразны) это может происходить очень часто.

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

Об этом в блоге оракла только лишь намекнули in addition. Основная мысль про чистку кеша при update, но это само собой понятно.

Нет. Не при каждом. Все-таки вы даже первый комментарий к блогу не прочитали, как я просил.

Вот это и является реальной проблемой: *некоторые* типы нагрузки. А вовсе не многопроцессорность.

Вот в блоге оракла (и немного в документации) - приведены фундаментальные проблемы кеша. Вот они действительно напрямую связаны с его размером.

Блажен кто верует. Но я за тех, кто сперва попробует и померяет. А потом уже решает:

http://www.geeksww.com/tutorials/database_management_systems/mysql/tips_and_tricks/mysql_query_cache_not_necessarily_a_bad_thing.php

И вам не советую читать эти блоги чтобы знать как работает кеш в mysql. У вас неправильное мнение сложилось теперь.

До распространения многоядерных процессоров эти типы нагрузки и не думали даже масштабировать. Но с появлением современных средств, оказалось нужно масштабировать.

ну сколько можно по третьему разу? да, нужно мерять. но если просят общих советов и их есть у нас.

Что, даже комментарии от разработчиков mysql? Это как минимум нечестно. Вам - можно читать (причем всякую муру), а мне - нет.