На практике много чего может создать проблемы. Не значит, что обязательно создаст.
И наоборот - на практике много что может принести пользу. В т.ч. и mysql cache.
Решение очень простое: практика; измерения и модификация настроек в соответствии с ними. Никаких "best practices" в виде "отключить кеш нафиг" или "сделать его 64Mb". Неужели все это столь сложно, madoff?
Забавно, а технический словарь говорит bug = ошибка, неисправность. Боюсь, только с вашей подачи смысл не изменится.
Мне сложно прогнозировать.
Интересно, а assigned to тоже ставят только чтобы не обидеть?
Если не понимаете, что полезные советы можно давать после получения адекватной информации - вы действительно дурак. А от вас поступил только огрызок топа.
Так что большинство предположений - вполне логичны. Уверены, что проблема локальна - попробуйте ее воспроизвести. Самый разумный совет.
Вполне может быть и проблема не на уровне вашего сервера. Приятно, конечно, что вы верите руководству ДЦ на слово - но это не исключает ничего. Какие, кстати, характеристики канала?
Например, в Debian отключены. Странно было бы менять умолчание в ядре - оно не просто так там именно таково. Забавно, что ты не знал.
Ага. Федора, наверное, "современный". С systemd and hookers.
Не уверен. Но да, похоже до сих пор "все просто" (вот совсем недавний статус).
В отличие от - я не лох и сперва поищу уже готовый багрепорт. О чудо, вот результат простейшего поискового запроса:
http://bugs.mysql.com/bug.php?id=37844
Status: Verified
А почему она *должна быть* одна-единственная? Неужели только мне это кажется багом.
Ну так "нужно мерять" - тоже общий совет. И более полезный чем ваш - т.к. работает в большем числе ситуаций (а ваша рекоммендация ТС про уменьшение кеша с 60 до 200 скорее всего просто не даст абсолютно ничего ему заметного, исключая смешную экономию памяти).
Что, даже комментарии от разработчиков mysql? Это как минимум нечестно. Вам - можно читать (причем всякую муру), а мне - нет.
Нет. Не при каждом. Все-таки вы даже первый комментарий к блогу не прочитали, как я просил.
Вот это и является реальной проблемой: *некоторые* типы нагрузки. А вовсе не многопроцессорность.
Вот в блоге оракла (и немного в документации) - приведены фундаментальные проблемы кеша. Вот они действительно напрямую связаны с его размером.
Блажен кто верует. Но я за тех, кто сперва попробует и померяет. А потом уже решает:
http://www.geeksww.com/tutorials/database_management_systems/mysql/tips_and_tricks/mysql_query_cache_not_necessarily_a_bad_thing.php
А почему толпа апачей не собирается?
Мопед не мой...
Нет, не все равно. Подрастешь - поймешь.
Для начала вам вовсе не обязательно на "купленном сервере" держать свой DNS сервер.
Это делается не так. Проще всего, если текущий ваш хостер предоставляет хостинг DNS. Тогда вы просто меняете IN A записи в зоне доменов, чтобы они указывали на ваш новый сервер, а не на хостера. Это достаточно быстрая процедура: данный тип записей в зоне "разойдется" обычно за полчаса-час (хотя бывают хостеры, которые TTL ставят и поболее: нужно смотреть).
Если вы поменяете NS на новые, причем на новом DNS-сервере будет уже совершенно иная зона, с IP указывающими на ваш новый сервер - то часть посетителей уйдет на старый сайт, а часть на новый. И это счастье может продолжаться куда дольше: до трех суток.
Лучше тогда делать в два этапа:
1) создаем на новых DNS-серверах ваши зоны один-в-один как на старых у хостера (за исключением NS-записей), меняем NS у регистратора и ждем 3+ суток
2) затем меняем нужные записи в зонах, чтобы они указывали на IP вашего сервера.
Если DNS-хостер ставит большие TTL для обычных записей - стоит уйти к другому. Хотя можно и такие записи менять, не потеряв ни одного запроса от клиентов.
Наймите нормального. Логично доверять сервер тому, от кого вы знаете что ожидать в какой срок.
В выводе phpinfo() написано какие конфигурационные файлы тот читает.
Байтики много куда пишутся.
Я расцениваю это как то, что на конкретный заданный вопрос вы ответа не знаете.
Ну вот и поделитесь. А то читает мои мысли, понимаешь, без спросу - щас милицию позову!
И это пишет человек, осиливший перевод элементарной фразы из документации со второй попытки?
