Конвертирование таблицы сессий в MEMORY

[2rough4u]

Господа, сегодня эксперимента ради конвертнул таблицу ibf_sessions в MEMORY (была стандартной MyISAM). Результат потрясающий - форум начал летать как самолёт! (100-150 человек в онлайне обычно)

 

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

 

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

 

Или я всё-таки в чём-то заблуждаюсь? Если нет - тогда я не понимаю, почему об этом нигде не пишут...

Изменено 7 Мая 2010 пользователем 2rough4u

[Ritsuka]

Все нормально. В крайнем случае все перезайдут. Хотя, на нормальных серверах аптаймы такие, что....

 

Правда, вариант не для shared-хостинга

[Sannis]

Просто не пишут. Точнее пишут(правда-правда, три темы помню), но в основном-то тут люди с шаредов

[2rough4u]

Идея в голову приходила еще год назад, наверное, но тогда было лень залезть в гугл и почитать дадашит на MEMORY. Сегодня залез, ознакомился - понял, что ничего страшного в этом типе таблиц нет и даже более того - есть много чего прекрасного! Изменено 7 Мая 2010 пользователем 2rough4u

[Arhar]

идея правильная, очевидная и разработчики могли сделать это искаропки, но они тоже не сильно круты

[malik]

Хоть на дворе уже 2014-й, но допишу своё наблюдение по данной теме, может кому-то будет важно.

Если у вас таблица ibf_sessions в MYISAM, то перевод её в MEMORY имеет смысл в плане увеличения скорости. Однако, если эта таблица в INNODB и клиентов много (у меня ~5000 онлайн за 15 минут), то даже и не пытайтесь - станет намного хуже, т.к. таблица в MEMORY или MYISAM при записи в неё блокируется вся (в отличие от INNODB), что при большом количестве запросов приведёт к затыку.

[Denis Chursinov]

Можно резюмировать, что sessions, content_cache_posts, content_cache_sigs, cache_store, core_item_markers, core_item_markers_storage, profile_portal_views, search_sessions,search_visitors, spider_logs, topic_views нужно держать в INNODB . Там полнотекстовый поиск точно не нужен, а запись довольно массированная.

 

Еще более быстрый вариант - гибрид. Надо оставить в INNODB минимальные таблицы по объему данных, возможно даже только sessions .

Выставить innodb_buffer_pool_size в пару гигабайт, innodb_flush_log_at_trx_commit = 0 . Буфер innodb общий для всего сервера MySQL , но если его объем больше объема всех таблиц INNODB на сервере, то таблицы будут всегда целиком в памяти. Скорость должна получиться почти как у memory, но без блокировок. Я пока не проверял, нет такого загруженного форума для экспериментов, но теоретически должно быть быстро.

 

Еще по поводу скорости INNODB

innodb_thread_concurrency = 0 это позволяет серверу самому решать, сколько ядер задействовать 0 - неограниченно а не ничего

innodb_read_io_threads и innodb_write_io_threads начиная с MySQL 5.1.38 выставить в 64

innodb_file_per_table тоже должен быть включен.