Тут мне сделали справедливое замечание, что указание tmp_table_size без max_heap_table_size не очень осмысленно, ибо выбирается меньшее значение, так что исправляюсь:
tmp_table_size = 2000M
max_heap_table_size = 2000M
Хотя особого смысла во временных таблицы в два гига нет. У меня эта настройка осталась после каких то игрищ с мускулом и поскольку реальная цифра была 16М то соответственно не использовалась.
А бэки тематические?
Куда столько? Вот и нету памяти.
На сайт что, заходит одновременно 1000 человек и открывается 1000 коннектов к базе? Что это за сайт такой? ;)
Реально с одной страницы обычно открывается один коннект к базе, независимо от количества генерируемых ею запросов, скрипт отработал - коннект грохнулся автоматом, память освободилась. Если использовать pconnect то он не грохается, а остается висеть и только занимает память.
Для примера у ресурса с посещаемостью 10к хостов в сутки Max used connections=40 при трехсуточном аптайме.
my.cnf
max_connections = 150 table_cache = 768 key_buffer_size = 1000M sort_buffer_size = 256M read_buffer_size = 256M read_rnd_buffer_size = 256M join_buffer_size = 256M tmp_table_size = 2000M query_cache_limit = 64M query_cache_size = 256M
Объем БД ~2.4GB, но вся база и индексы помещаются в ОЗУ (6гб) pconnect-ы не используются.
Вот LA сейчас глянул: 1.36, 1.85, 2.01. Серв-2 x XEON
А гугл вообще в последнее время озверел, грызет сайты злее вебальты. А вот яндекс как-то малопредсказуем. Старые сайты более менее регулярно индексирует, а вот смотрю свежий сайт целый месяц матросил-матросил и бросил :) второй день вообще тишина, даже роботс.тхт не проверял...
А кто сказал, что яндекс обязан за две недели показать сайт в выдаче?
Нужно еще подождать.
Ааа. Понятно. Знакомые грабли.
Не знаю конечно, что за софт используется, может ему это действительно нужно, но, как показывает практика, использование pconnect приводит только к перерасходу памяти, не давая ничего взамен.
Рекомендую использовать простой connect и будет счастье.
А корпуса лучше вообще не подбирать, а брать готовые брендовые платформы, которые рассчитаны и на горячие камни и на скази диски, в которых гарантированно нормальное охлаждение. В такую платформу выбираются только камни, мозги и харды из списка валидированного производителем оборудования.
Точно не помню, но скорее всего да, весной прошлого года перерыл буквально все.
persistent коннекты используются?
И это правильно.
И это тоже правильно. Но когда райд контроллер совсем тормоз и когда на диск падает что-то сравнимое с размером ОЗУ, например какая нибудь обработка БД, которая генерит огромную таблицу с кучей индексов и система встает колом минут на 10 с iowait=100%, то разница в скорости записи 45мб/сек и 10мб/сек чувствуется очень сильно.
Порты рулез форева :), но вот почему я отказался от фряхи, так это потому что не смог решить проблему с мониторингом на 1475 платформе (ICH7R+LM85). mbmon заброшен, других решений просто не существует похоже. Под линухом хоть lm_sensors худо-бедно новое железо знает.. Так что везде есть проблемы.
