Freebsd + куча вп Hdd не справляется

[MyName]

сабж.

как можно оптимизировать?
вп порядка 600 шт + по мелочи сайтики. стоит w3 total cache кеширует mysql страницы не кешируется. (для одного плагина надо обновление страниц в реальном времени.)

на серваке ram 16GB есть мысль туда что-то перекинуть в tmpfs.

сейчас mysql'ю там выдано место для временных таблиц. работать стало быстрее но все равно морозится особенно при наплыве ботов.
так же стоит apc с размером кеша 780 mb пробовал ставить больше но % попаданий в кеш существенно не увеличивается что при 1gb что при 2gb 1 фиг. W3 в него не пишет т.к. раньше было все настроенно без него сейчас менять замучаешся... да и 600+ блогов в кеш запихнуть достаточно проблематично
mysql на кешы тоже рам выдано прилично

конфиг:

PHP код:

[MYSQLD]
tmpdir=/mnt/mysqltmp
skip-locking
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 2M

    key_buffer_size=256M
    query_cache_size=2G
    query_cache_limit=512M
    tmp_table_size=384M
    max_heap_table_size=384M
    thread_cache_size=16
    table_cache=64000
    innodb_buffer_pool_size=128M
    max_connections=1000
    wait_timeout =2500
    interactive_timeout=2500
thread_concurrency = 8

skip-federated
skip-bdb
skip-name-resolve 


mysqltuner:

PHP код:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.92
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1G (Tables: 8029)
[--] Data in InnoDB tables: 8M (Tables: 6)
[--] Data in MEMORY tables: 0B (Tables: 12)
[!!] Total fragmented tables: 295

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 57m 59s (107K q [30.855 qps], 10K conn, TX: 358M, RX: 17M)
[--] Reads / Writes: 89% / 11%
[--] Total buffers: 2.8G global + 6.4M per thread (1000 max threads)
[OK] Maximum possible memory usage: 9.0G (52% of installed RAM)
[OK] Slow queries: 0% (409/107K)
[OK] Highest usage of available connections: 55% (559/1000)
[OK] Key buffer size / total MyISAM indexes: 256.0M/138.3M
[OK] Key buffer hit rate: 97.9% (668K cached / 14K reads)
[OK] Query cache efficiency: 42.7% (30K cached / 70K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 6K sorts)
[!!] Temporary tables created on disk: 38% (4K on disk / 11K total)
[OK] Thread cache hit rate: 88% (1K created / 10K connections)
[OK] Table cache hit rate: 99% (8K open / 8K opened)
[OK] Open file limit used: 18% (17K/90K)
[OK] Table locks acquired immediately: 99% (60K immediate / 60K locks)
[OK] InnoDB data size / buffer pool: 8.2M/128.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Enable the slow query log to troubleshoot bad queries
    Temporary table size is already large - reduce result set size
    Reduce your SELECT DISTINCT queries without LIMIT clauses 


hdd с отключенным апачем

PHP код:

# diskinfo -t ada0
ada0
        512             # sectorsize
        500107862016    # mediasize in bytes (466G)
        976773168       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        969021          # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        5VJ8MPVP        # Disk ident.

Seek times:
        Full stroke:      250 iter in   7.160039 sec =   28.640 msec
        Half stroke:      250 iter in   4.539064 sec =   18.156 msec
        Quarter stroke:   500 iter in   6.842026 sec =   13.684 msec
        Short forward:    400 iter in   3.325927 sec =    8.315 msec
        Short backward:   400 iter in   3.012394 sec =    7.531 msec
        Seq outer:       2048 iter in   0.165592 sec =    0.081 msec
        Seq inner:       2048 iter in   0.584486 sec =    0.285 msec
Transfer rates:
        outside:       102400 kbytes in   0.995734 sec =   102839 kbytes/sec
        middle:        102400 kbytes in   1.160060 sec =    88271 kbytes/sec
        inside:        102400 kbytes in   1.930989 sec =    53030 kbytes/sec 


hdd с включенным апачем

PHP код:

s114# diskinfo -t ada0
ada0
        512             # sectorsize
        500107862016    # mediasize in bytes (466G)
        976773168       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        969021          # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        5VJ8MPVP        # Disk ident.

Seek times:
        Full stroke:      250 iter in 660.203254 sec = 2640.813 msec
        Half stroke:  
дальше не дождался да и вообще похоже что он повесился.... 


wp сайты - сплоги так что потеря небольшой части данных не критична.
думаю перекидывать при загрузки все базы на ram диск при загрузке и раз в полчаса-час по крону копировать их на hdd

но тут вопрос.. как подобный процесс пройдет при запущенном mysql и соответственно возможно изменяемой бд.... не грохнитсяли база? + надо учитывать что на hdd нагрузка может быть от чтения php файлов соответственно процесс может затянутся

может кто с подобной проблеммой сталкивался и есть какие-то решения?

[medar]

wiam, в общем, у меня для тебя плохие новости. Ты, похоже, уперся в недостаток архитектуры wp и это не лечится ни безусловно нужным wp-super-cache, ни оптимизацией на уровне сервера. Ну, если не уперся - то обязательно упрешься через некоторое время.

У wp есть один запросик, если не ошибаюсь, он строит пагинацию. Для пагинации нужно знать количество постов по данному тэгу, месяцу, категории и т.п. Этот запрос дико медленный, и еще и с GROUP BY. Какое суперкэширование ты не ставь - рано или поздно кэш придется обновлять. Особенно если ты постишь часто (часто - это не пост в 1-2 дня, а чаще). Этот запрос заставляет mysql шерстить всю базу posts. Этот запрос выполняется долго, и он, к тому же, лочит таблицу, так как MyISAM. Если блогов много, то рано или поздно момент инвалидации кэшей наступает у двух или более блогов. И тогда наступает эффект снежного кома, когда одно начинает тормозить другое, растет число ожидающих коннектов, начинает есться память и все начинает тормозить еще больше.

Выход из этого - только патчить код wp. Вот тут описана сия проблема и решение: http://x-pose.org/2011/08/fix-the-wo...ound_rows-bug/

Открытый тикет с этой проблемой так и не пофиксили, по крайней мере в 3.2.1.

[chesser]

Сообщение от wiam

это как ?

про починку индексов - это я имел ввиду добавь key_buffer_size

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

можно через админку, или написать скрипт на php, чтобы облегчить рутинные нажатия кнопок. Можно напрямую из базы, но это сложнее, т.к. там не одна таблица, а связка таблиц. И удалять обязательно нужно изо всех таблиц, чтобы не нарушить целостность индексов. Как вариант, можно временно сконвертить таблицы в innodb, настроить автоматическое сохранение целостности сущеностей и дальше удалять только в одной главной таблице сущности, вроде wp_terms

medar, либо переходить на друпал. Я специально смотрел эту проблему там. Она там решена: там нет того дополнительного ужасного JOIN'а при запросе таксономий, т.е. они используют кеширование sql-таблиц в избыточные sql-таблица, понижая "начальную форму". И плюс обычное кеширование друпала вроде тоже помогает, тут точно не помню уже.

Но у меня был опыт запуска большой сетки вп блогов, я так и не уперся в снежный ком. Тормозило конечно, но чтобы прям совсем пиздец - такого не было. Все таки оптимизация прибавляет много мощи. раз в 20-50 можно разогнать

[wiam]

Спасибо за ответы/советы. В существующей пачке блогов почищу теги и категории, плагины по-отрубал уже. Ну и походу nginx+php_fpm+xcache/apc+кеширование страниц с помощью nginx будет самым нормальным вариантом. Ну а на будущее drupal.