Тут мне сделали справедливое замечание, что указание 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 при трехсуточном аптайме.
satyr: сайт в зоне .de. Тоже жду уже более 3х месяцев... не индексирует. Google со всех зон - сразу сожрал...
А гугл вообще в последнее время озверел, грызет сайты злее вебальты. А вот яндекс как-то малопредсказуем. Старые сайты более менее регулярно индексирует, а вот смотрю свежий сайт целый месяц матросил-матросил и бросил :) второй день вообще тишина, даже роботс.тхт не проверял...
Не знаю конечно, что за софт используется, может ему это действительно нужно, но, как показывает практика, использование pconnect приводит только к перерасходу памяти, не давая ничего взамен.
Рекомендую использовать простой connect и будет счастье.
Lupus: При условии правильного подбора корпуса. Иначе - существенно чаще. Установка их в 1U вместе с несколькими горячими камнями, вопрос очень спорный.
А корпуса лучше вообще не подбирать, а брать готовые брендовые платформы, которые рассчитаны и на горячие камни и на скази диски, в которых гарантированно нормальное охлаждение. В такую платформу выбираются только камни, мозги и харды из списка валидированного производителем оборудования.
Lupus: Кузов надо с нормальной вентиляцией использовать. И кондишны в серверной.
И это правильно.
В реальном, боевом сервере, который не просто пишет/читает гигабайтные файлы, а делит HDD между сотней-другой процессов, куда важнее производительность ФС. FreeBSD, собранная под 64 разряда (родная разрядность UFS) с диском работает в разы быстрее, чем при 32-х разрядах.
И это тоже правильно. Но когда райд контроллер совсем тормоз и когда на диск падает что-то сравнимое с размером ОЗУ, например какая нибудь обработка БД, которая генерит огромную таблицу с кучей индексов и система встает колом минут на 10 с iowait=100%, то разница в скорости записи 45мб/сек и 10мб/сек чувствуется очень сильно.
Не скажу за Linux, но фря имеет самые свежие драйвера практически всегда. А в отличие ои винды, она обновляется практически ежедневно. И никаких "трахов" с пересборкой ядра.
Порты рулез форева :), но вот почему я отказался от фряхи, так это потому что не смог решить проблему с мониторингом на 1475 платформе (ICH7R+LM85). mbmon заброшен, других решений просто не существует похоже. Под линухом хоть lm_sensors худо-бедно новое железо знает.. Так что везде есть проблемы.
Тут мне сделали справедливое замечание, что указание tmp_table_size без max_heap_table_size не очень осмысленно, ибо выбирается меньшее значение, так что исправляюсь:
tmp_table_size = 2000M
max_heap_table_size = 2000M
Хотя особого смысла во временных таблицы в два гига нет. У меня эта настройка осталась после каких то игрищ с мускулом и поскольку реальная цифра была 16М то соответственно не использовалась.
а тИЦ 0 и не растёт никак....,
А бэки тематические?
p.s. стоит max_connections=1000 , хватает ,
Куда столько? Вот и нету памяти.
На сайт что, заходит одновременно 1000 человек и открывается 1000 коннектов к базе? Что это за сайт такой? ;)
Реально с одной страницы обычно открывается один коннект к базе, независимо от количества генерируемых ею запросов, скрипт отработал - коннект грохнулся автоматом, память освободилась. Если использовать pconnect то он не грохается, а остается висеть и только занимает память.
Для примера у ресурса с посещаемостью 10к хостов в сутки Max used connections=40 при трехсуточном аптайме.
my.cnf
Объем БД ~2.4GB, но вся база и индексы помещаются в ОЗУ (6гб) pconnect-ы не используются.
Вот LA сейчас глянул: 1.36, 1.85, 2.01. Серв-2 x XEON
сайт в зоне .de. Тоже жду уже более 3х месяцев... не индексирует. Google со всех зон - сразу сожрал...
А гугл вообще в последнее время озверел, грызет сайты злее вебальты. А вот яндекс как-то малопредсказуем. Старые сайты более менее регулярно индексирует, а вот смотрю свежий сайт целый месяц матросил-матросил и бросил :) второй день вообще тишина, даже роботс.тхт не проверял...
А кто сказал, что яндекс обязан за две недели показать сайт в выдаче?
Нужно еще подождать.
да , используется pconnect везде
Ааа. Понятно. Знакомые грабли.
Не знаю конечно, что за софт используется, может ему это действительно нужно, но, как показывает практика, использование pconnect приводит только к перерасходу памяти, не давая ничего взамен.
Рекомендую использовать простой connect и будет счастье.
При условии правильного подбора корпуса. Иначе - существенно чаще. Установка их в 1U вместе с несколькими горячими камнями, вопрос очень спорный.
А корпуса лучше вообще не подбирать, а брать готовые брендовые платформы, которые рассчитаны и на горячие камни и на скази диски, в которых гарантированно нормальное охлаждение. В такую платформу выбираются только камни, мозги и харды из списка валидированного производителем оборудования.
healthd пробовали?
Точно не помню, но скорее всего да, весной прошлого года перерыл буквально все.
для примера:
оперативы 2 Гб не хватает! хотя проц xeon 3.0 20% idle
persistent коннекты используются?
Кузов надо с нормальной вентиляцией использовать. И кондишны в серверной.
И это правильно.
И это тоже правильно. Но когда райд контроллер совсем тормоз и когда на диск падает что-то сравнимое с размером ОЗУ, например какая нибудь обработка БД, которая генерит огромную таблицу с кучей индексов и система встает колом минут на 10 с iowait=100%, то разница в скорости записи 45мб/сек и 10мб/сек чувствуется очень сильно.
Порты рулез форева :), но вот почему я отказался от фряхи, так это потому что не смог решить проблему с мониторингом на 1475 платформе (ICH7R+LM85). mbmon заброшен, других решений просто не существует похоже. Под линухом хоть lm_sensors худо-бедно новое железо знает.. Так что везде есть проблемы.