CacheRouter - как правильно?

Главные вкладки

Аватар пользователя andribas@drupal.org andribas@drupal.org 22 ноября 2010 в 19:41

Здравствуйте!
Поставил CacheRouter и сделал default engine = APC
APC = 256Mb
80mb скушали скрипты, 170 осталось под кеш.
Эти 170м очень быстро скушались, и память кончилась.
Насколько я понял, в CacheRouter нет политики кеширования типа LRU, считается, что ресурс безлимитный.

Сколько ему памяти надо для кеша?
Дело тут не столько в том, что нужен прирост скорости - после того, как я сделал default engine = db,
drupal стал насиловать mysql.
Поэтому хочу спросить, могу ли я в ядре уменьшить значение $expire, к примеру до часа или двух

<?php
//    includes/form.inc
function form_set_cache($form_build_id$form$form_state) {
  global 
$user;
  
// 6 hours cache life time for forms should be plenty.
  
$expire 21600;
?>

поскольку 150Мб как-то многовато для кеша.

Ну и по сабжу, как правильно посчитать размер памяти, необходимый сабжу CacheRouter для работы, чтобы ее хватало?
Поскольку на сервере ведется бинарный лог, и за сутки он стал 8Г

Трафик 1 ø в час
Принято 15 ГБ 472 МБ
Отправлено 165 ГБ 5,181 МБ
Всего 180 ГБ 5,653 МБ

MySQL сервер работает 1 дней, 8 часов, 36 минут и 12 секунд. Время запуска: Ноя 21 2010 г., 12:53.

я его вчера перезапускал, но что-то мне эта статистика не очень нравится.
Почистил логи - reset master, за час уже наросло 400мб, откуда столько?

Как сделать по уму?

попробовал вот эту штуку, чтобы понять, вот что она пишет:

#mysqlbinlog /var/lib/mysql/mysqld.000001 | perl mysqlsla --log-type binary

Report FOR BINARY logs: -
56.20k queries total, 81 UNIQUE
Sorted BY 'c_sum'

COUNT             : 5.36k (9.53%)
SET TIMESTAMP=N/*!*/; UPDATE cache_views_data SET DATA = 'S', created = N, expire = N, headers = 'S', serialized = N WHERE cid = 'S' /*!*/;

COUNT             : 4.74k (8.43%)
SET TIMESTAMP=N/*!*/; INSERT INTO cache_filter (cid, DATA, created, expire, headers, serialized) VALUES ('S', 'S', N, N, 'S', N) /*!*/1;

COUNT             : 4.74k (8.43%)
SET TIMESTAMP=N/*!*/; UPDATE cache_filter SET DATA = 'S', created = N, expire = N, headers = 'S', serialized = N WHERE cid = 'S' /*!*/;

COUNT             : 4.00k (7.12%)
SET TIMESTAMP=N/*!*/; UPDATE variable SET VALUE = 'S' WHERE name = 'S' /*!*/;

COUNT             : 4.00k (7.12%)
SET TIMESTAMP=N/*!*/; DELETE FROM cache WHERE cid = 'S' /*!*/;

COUNT             : 3.26k (5.80%)
SET TIMESTAMP=N/*!*/; UPDATE cache SET DATA = 'S', created = N, expire = N, headers = 'S', serialized = N WHERE cid = 'S' /*!*/;

COUNT             : 3.15k (5.61%)
SET TIMESTAMP=N/*!*/; INSERT INTO cache (cid, DATA, created, expire, headers, serialized) VALUES ('S', 'S', N, N, 'S', N) /*!*/1;

COUNT             : 2.94k (5.24%)
SET TIMESTAMP=N/*!*/; UPDATE cache_content SET DATA = 'S', created = N, expire = N, headers = 'S', serialized = N WHERE cid = 'S' /*!*/;

COUNT             : 2.94k (5.24%)
SET TIMESTAMP=N/*!*/; INSERT INTO cache_content (cid, DATA, created, expire, headers, serialized) VALUES ('S', 'S', N, N, 'S', N) /*!*/1;

COUNT             : 2.75k (4.89%)
UPDATE node_counter SET daycount = daycount + 1, totalcount = totalcount + 1, TIMESTAMP = 1290439702 WHERE nid = 300057

Комментарии

Аватар пользователя andribas@drupal.org andribas@drupal.org 22 ноября 2010 в 20:15

сейчас таблицы такого размера: (после очистки кеша)

cache           1.4 МБ
cache_block     11.0 КБ
cache_content   11.4 МБ
cache_filter    9.7 МБ
cache_form      151.0 МБ
cache_menu      1.3 МБ
cache_page      12.2 КБ
cache_update    783.3 КБ
cache_views     261.8 КБ
cache_views_data1.6 МБ

может в APC не все положить, а там где трфик самый большой?

Возможно, причина в том, что я установил Минимальное время жизни кэша: 1 мин., но делалось это для того, чтобы снизить потребляемый объем памяти этим самым кешем

Anonymous page caching : off, boost тоже выключил, кеширование блоков включено, в чем может быть причина?

Аватар пользователя Fanny@drupal.org Fanny@drupal.org 22 ноября 2010 в 21:51

Я применяю, применяю на файлах, на другое чтото не очень взлетает, ресурсы сжираются, толку мало.

Задавал аналогичный по смыслу вопрос - толком не вышли на ответ... ;(

Аватар пользователя andribas@drupal.org andribas@drupal.org 22 ноября 2010 в 22:07

Сейчас выключил кеширование views - вроде на производительность вообще не влияет, возможно, я не совсем понимаю, как он кеширует, но запросов к бд у него больше всего.
у меня к примеру 10 views без аргументов, без node access, я полагал, что будет 10 записей в кеше, который обновляется раз в минуту (стоял кеш 1мин / 1 мин).
а на деле получилось 18к запросов за 2.5 часа = 120 в минуту / 10 = 1 запрос раз в 5 сек на каждый view - откуда столько?

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

Аватар пользователя andribas@drupal.org andribas@drupal.org 22 ноября 2010 в 22:16

boost кстати в базу тоже дохрена пишет, так что, возможно, Crea был прав, что varnish лучше!
просто я на роботах нагрузки не видел, так в принципе все нормально, но сейчас меня такой объем трафика 6 гигабайт в час между сайтом и сервером mysql на localhost не устраивает, я наружу в сто раз меньше отдаю!! Smile

Без кеширования сайт тормозит, а с кешированием мускул насилует.

Аватар пользователя andribas@drupal.org andribas@drupal.org 22 ноября 2010 в 23:59

запостил issue в drupal core http://drupal.org/node/978942 - у меня почему-то не чистится cache_form,
без нее весь кеш будет весить немного, попробую memcached, спасибо Вам за помощь!

еще sessions, captcha_sessions непонятно, их кто-нибудь чистит?
вроде не кеш, но сессий уже много накопилось.

UPD: по умолчанию сессии живут 3 недели?:

<?phpfunction sess_gc($lifetime) {
  // Be sure to adjust 'php_value session.gc_maxlifetime' to a large enough
  // value. For example, if you want user sessions to stay in your database
  // for three weeks before deleting them, you need to set gc_maxlifetime
  // to '1814400'. At that value, only after a user doesn't log in after
  // three weeks (1814400 seconds) will his/her session be removed.
  db_query("DELETE FROM {sessions} WHERE timestamp < %d", time() - $lifetime);

  return TRUE;
}
?>

капча живет сутки

<?php/**
 * Implementation of hook_cron().
 *
 * Remove old entries from captcha_sessions table.
 */
function captcha_cron() {
  // remove challenges older than 1 day
  db_query('DELETE FROM {captcha_sessions} WHERE timestamp < %d', time() - 60*60*24);
}
?>

уменьшил время жизни сессий до 3 дней, правда не уверен что верно:

<?phpsites/default/settings.php
ini_set('session.cache_expire',     4320); // in minutes = 3 days, default 200000 = 138 days?
ini_set('session.cache_limiter',    'none');
ini_set('session.cookie_lifetime',  2000000); //cookie in user browser
ini_set('session.gc_maxlifetime',   200000); // 1 day+ - default
?>

вроде как значение берется из gc_maxlifetime, а оно по умолчанию 1 день.

Аватар пользователя gorr gorr 23 ноября 2010 в 2:30

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

Аватар пользователя andribas@drupal.org andribas@drupal.org 23 ноября 2010 в 13:47

Кажется я нашел ошибку c cache_form
Проблема не в ядре, а в модуле ajax_comments + cacherouter - кто-то из них работает неправильно

в функции function ajax_comments_cache_get($cid, $table = 'cache') {
сделал //variable_set('cache_flush', 0);

и перенес ее в

<?php    else {
    
variable_set('cache_flush'0);
    
db_query("DELETE FROM {"$table ."} WHERE expire != %d AND expire <= %d"CACHE_PERMANENT$cache_flush);
    }
?>

т.к. если ее обнулить и отправить запрос на очистку кеша, то cacherouter никогда не будет чистить кеш этой таблицы.
это работает только с cacherouter 6.x-1.0-rc1, поскольку в dev версии cacherouter название переменной cache_flush стандартизовано в соответствии с кешем ядра и называется 'cache_flush_'.$table
ajax_comments использую dev.
без cacherouter все должно нормально работать, т.к. кеш чистится запросом к mysql.

Возможно, neochief что-нибудь исправит Smile

UPD: это исправление не помогает, я почистил cache_clear_all(NULL,'cache_form'); вручную, ошибку еще надо искать

Аватар пользователя andypost@drupal.org andypost@drupal.org 23 ноября 2010 в 13:52

Нужно править ajax_comments чтобы соответствовал cache_flush ядра, иначе абсурд получается - кеш не будет чиститься.

По части использования cacherouter - он для того и предназначен, чтобы разные таблицы (кеши) хранить в разных бэках. Например, cache, cache_page положить в APC а остальные в файлы или мемкеш.

Аватар пользователя andribas@drupal.org andribas@drupal.org 24 ноября 2010 в 21:30

за сутки прироста comment_form не обнаружил, т.е. исправление function ajax_comments_cache_get($cid, $table = 'cache') помогло.
Поставил memcached, настроил CacheRouter на него, полет нормальный.
Единественное, не очень понял что означает вывод memcached-tool 127.0.0.1:11211 stats
в APC теперь хранятся только сами файлы php, ini - нужно примерно 40Мб на 1 сайт друпала.

в cacherouter/engines/memcache.php есть опечатка (версия не дев):
66: if ($expire == CACHE_TEMPORARY || $expire == CACHE_PERMENANT) {

теперь поставил в my.cnf

min_examined_row_limit                  = 1000
log_queries_not_using_indexes           = 1
slow_query_log                          = 1
slow_query_log_file                     = /var/log/mysql/slow_query.log
long_query_time                         = 0.5

буду ловить неоптимизированные запросы со временем больше 0.5сек или больше 1к строк скан и добавлять индексы / оптимизировать запросы.
1 запрос уже нашел - в комментах добавил индекс по дате.