Freebsd + куча вп Hdd не справляется - Форум успешных вебмастеров

MyName · 03.12.2011, 12:50

сабж.

как можно оптимизировать?
вп порядка 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 файлов соответственно процесс может затянутся

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

chesser · 03.12.2011, 13:15

Цитата:

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

это ж как красная тряпка ))

MyName · 03.12.2011, 13:20

Цитата:

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

это ж как красная тряпка ))

думаешь ngnix будет меньше с hdd сношатся?

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

chesser · 03.12.2011, 13:27

Цитата:

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

думаешь ngnix будет меньше с hdd сношатся?

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

апач нужен для организации масс-хостинга. имхо
когда у тебя в распоряжении минимум впс - это уже другие решения.

Глянь мой ман по оптимизации сервера. Если там что непонятно будет, спрашивай прям здесь.

и ты эта... завязывай там с рам дисками

этот бред
в мускуле для этого есть таблицы типа memory, да и правильная настройка в my.cnf должна дать тот же эффект, что и помещение бд в рам.

UPD: покажи top
UPD2: поставь мунин блеать

MyName · 03.12.2011, 13:35

Цитата:

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

апач нужен для организации масс-хостинга. имхо
когда у тебя в распоряжении минимум впс - это уже другие решения.

Глянь мой ман по оптимизации сервера. Если там что непонятно будет, спрашивай прям здесь.

и ты эта... завязывай там с рам дисками

этот бред
в мускуле для этого есть таблицы типа memory, да и правильная настройка в my.cnf должна дать тот же эффект, что и помещение бд в рам.

UPD: покажи top
UPD2: поставь мунин блеать

топ

PHP код:


			
last pid:  2019;  load averages:  0.46,  0.51,  0.50    up 0+00:30:17  09:29:00

810 processes: 2 running, 808 sleeping

CPU: 11.7% user,  0.0% nice,  1.1% system,  0.0% interrupt, 87.1% idle

Mem: 5663M Active, 4274M Inact, 1927M Wired, 1646M Buf, 3985M Free

Swap: 8192M Total, 8192M Free



  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND

 1698 www         1  55    0   909M   190M accept  1   0:05  3.17% httpd

 1696 www         1  44    0   909M   183M select  0   0:04  1.95% httpd

 1784 www         1  46    0   919M   188M select  2   0:02  1.86% httpd

 1798 www         1  46    0   909M 86736K accept  1   0:01  1.76% httpd

 1995 www         1  47    0   911M   158M accept  0   0:03  1.56% httpd

 1770 www         1  46    0   929M   216M getblk  1   0:02  1.56% httpd

 1678 www         1  46    0   927M   234M biord   1   0:05  1.46% httpd

 1677 www         1  46    0   911M   203M accept  3   0:05  1.37% httpd

 1661 www         1  46    0   927M   180M biord   1   0:02  1.37% httpd

 1832 www         1  46    0   905M   194M accept  1   0:02  1.27% httpd

 1998 www         1  46    0   929M   143M biord   3   0:02  1.27% httpd

 1802 www         1  45    0   907M   135M select  2   0:02  1.17% httpd

 1703 www         1  45    0   927M   194M select  1   0:03  1.07% httpd

 1768 www         1  45    0   911M   152M accept  2   0:03  1.07% httpd

 1757 www         1  46    0   927M   126M vnread  2   0:03  0.98% httpd

 1835 www         1  46    0   927M   130M sbwait  1   0:01  0.98% httpd

 1946 www         1  44    0   925M   144M biord   1   0:01  0.68% httpd

 1710 www         1  45    0   915M   194M getblk  1   0:06  0.59% httpd

 1713 www         1  46    0   911M   146M accept  1   0:02  0.59% httpd

 1829 www         1  48    0   905M   133M accept  2   0:02  0.59% httpd

 1763 www         1  45    0   907M   146M accept  0   0:02  0.59% httpd

 1804 www         1  45    0   915M   176M getblk  3   0:02  0.49% httpd

 1783 www         1  45    0   915M   127M accept  3   0:02  0.49% httpd

 1923 www         1  44    0   905M   196M accept  0   0:04  0.29% httpd

 1747 www         1  45    0   915M   171M getblk  1   0:03  0.29% httpd

 1669 www         1  45    0   905M   123M accept  0   0:02  0.29% httpd

 1681 www         1  45    0   913M   659M getblk  0   0:02  0.29% httpd

 1906 www         1  44    0   907M   129M CPU0    0   0:01  0.29% httpd

 1694 www         1  46    0   905M   181M accept  2   0:04  0.20% httpd

 1936 www         1  44    0   929M   186M sbwait  0   0:03  0.20% httpd

 1897 www         1  45    0   909M   129M accept  0   0:02  0.20% httpd

 1674 www         1  44    0   909M   216M select  2   0:05  0.10% httpd

 1686 www         1  45    0   927M   231M sbwait  2   0:04  0.10% httpd

 1717 www         1  45    0   913M   118M getblk  2   0:02  0.10% httpd

 1118 mysql     424  44    0  3095M   553M sbwait  2   0:08  0.00% mysqld

остальное попозже отойти надо.

в целом все работает как надо но время от времени начинает морозится. такое ощущение что или апачь добивает куча php файлов на 600 доменов или майскуль 8к таблиц.

tmpfs помогла с временными таблицами mysql т.к. он даже при кешах в 4GB на временные таблицы все равно 40% писал на hdd

спасибо за ссылку покурю.. может что найду. тут проблема основная в том что куча в принцепе одинаковых таблиц и php файлов котьорые os поидеи считает разными....

хм... может ему попробовать как нить WP через симилинки ужать... + раскидать 400 доменов по подпапкам (сейчас в одной папке ютятся типа /home/400domains/domain1 - /home/400domains/domain400

chesser · 03.12.2011, 14:22

ну мы как-то с пареньком поднимали ВПС и 4к доменов, каждый домен - это статичный html сайт-дор. У него все было на апаче, la было какое-то запредельное 50 что-ли

сервер ребутило каждые полчаса, ну короче вообще ничего не работало. когда nginx поставил все завелось, но диски наверно стонут - hot set'ов мало, cpu свободен, но la=3-5 за счет wa, но тут уже scale-up надо делать. Это я к тому, что диск и не такое как у тебя может выдержать.

Попробуй снизь саму нагрузку, поотключай все что можно, все говноплагины. Сделай 304 хедер на всю статику.
Чтобы работал кеш на myisam, нужно перестать писать в таблицы, иначе он каждый раз ресетит кеш. Нужно смотреть что за запросы у тебя доминируют.

по мускулу:

Цитата:

Reads / Writes: 89% / 11%

а что как дохера пишется? 11% - это очень много для статичного сплога, значит есть динамика - а это уже ресурсы

Цитата:

Temporary tables created on disk: 38% (4K on disk / 11K total)

их надо запихать в память стандартными способами, т.е. настройками my.cnf, а не рам дисками

Цитата:

учитывать что на hdd нагрузка может быть от чтения php файлов соответственно процесс может затянутся

вот это надо скинуть в apc кеш, который file-кеш, а не var-кеш. Точно не помню, но там вроде кеш переменных и кеш байт-кодовых файлов разделены по разным настройкам.

Alexsize · 03.12.2011, 14:30

nginx fpm

key_buffer_size=256M

Ставь четвертть от рамы.

innodb - выруби все с ней связанное, у тебя myisam везде.

query_cache_size=512M
query_cache_limit = 2M

Выстави так, больше нема смысла.

log-slow-queries= /tmp/slow_queries.log

Глянь что у тебя косит базу.

По апачу - сноси нахер.
Если не хочешь - вырубай модули. Судя по памяти что он отжирает, там дохера ненужного.
Логи все выруби апача, это ЛОЛ такое колво логгировать - вот тебе диск и падает. (я правда не читал, вырубил ты логи аль нет =))
Вообще все логирование выруби нахер.
Слоу куверис потом тоже выруби.
Сервак выруби. Шутка.

chesser · 03.12.2011, 14:46

Цитата:

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

key_buffer_size=256M

Ставь четвертть от рамы.

зачем??? бред имхо

тем более:

Цитата:

Key buffer size / total MyISAM indexes: 256.0M/138.3M

medar · 03.12.2011, 15:29

wp большие (по количеству постов) ?

А как именно hdd не справляется ? По top у тебя все ок. Давай top в момент траблов.

Увеличь tmp_table_size в конфиге мускуля до 512M, например, очень много пишется на диск, при такой памяти этого не должно быть.

UPD1 Еще есть http://day32.com/MySQL/ - mytuner.sh
Им еще можно продиагностироваться.
Посмотри в конце на локи таблиц, если 1:2000 - ок, а если 1:200 , то надо переводить некоторые таблицы на innodb или выяснять, что так аццки пишется в mysql.

Aston Martim · 03.12.2011, 17:19

gstat то что показывает в момент нагрузки?