Выбор hdd сервера для посещаемого сайта.

Не слушайте глупости про необходимые эксклюзивные настройки.

Ваш сайт будет работать нормально с дефолтными настройками линукса даже на одном SATA диске без RAID'а. 4 диска в RAID 10 - это Вашему сайту надолго "на вырост" хватит.

Если у Вас возникнет проблема с нагрузкой, то только в случае кривых запросов к MySQL или посыпавшихся индексов в таблице. Это все исправляется за 2 минуты и не требует покупки мегажелеза или супертюнинга настроек ОС или файловой системы.

Ну а как тогда правильнее, завершать зависшие процессы по ssh?

Ну я говорю. Этого хватит?

Мало того, что высокая отказоустойчивость, так еще и производительность высокая.

Подробнее можно?

Некоторые ошибки уже исправлял ранее.

Когда то был еще некорректно удален модуль галереи, в панели гугл вебмастер до сих пор иногда ссылки какие то пишутся.

Что за бред? Отлично живет и в 4гб.

Минимум нужно 1.5 гб ей.

4 гб будет подтормаживать при объемах райда больше 500ГБ (личный опыт).

Но меньше - вполне нормально себя чувствует.

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

Правильно - поставить мониторинг (munin, например), через сутки посмотреть на график, увидеть там примерно вот такое: http://clip2net.com/s/2LuNR , убедиться в том, что память используется для кеширования и успокоиться.

---------- Добавлено 28.01.2013 в 20:18 ----------

Да, конечно: http://dev.mysql.com/

---------- Добавлено 28.01.2013 в 20:24 ----------

ТС, сделайте в консоли от рута следующее:

1) Скачайте скрипт: https://raw.github.com/rackerhacker/MySQLTuner-perl/master/mysqltuner.pl

Запустите, покажите нам вывод

2)

# mysql

> show processlist;

И покажите вывод. Может мы ваши винты вылечим удаленно ;)

Не совсем понял что нужно сделать.

# wget --no-check-certificate https://raw.github.com/rackerhacker/MySQLTuner-perl/master/mysqltuner.pl

# chmod +x ./mysqltuner.pl

# ./mysqltuner.pl

это вводим по ssh?

---------- Добавлено 28.01.2013 в 20:29 ----------

Ну вот что получили:

-------- Storage Engine Statistics -------------------------------------------

[--] Status: +Archive -BDB +Federated +InnoDB -ISAM -NDBCluster

[--] Data in MyISAM tables: 11M (Tables: 77)

[--] Data in InnoDB tables: 1M (Tables: 30)

[!!] Total fragmented tables: 8

-------- Security Recommendations -------------------------------------------

[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------

[--] Up for: 1d 10h 40m 14s (2M q [17.600 qps], 111K conn, TX: 2B, RX: 187M)

[--] Reads / Writes: 54% / 46%

[--] Total buffers: 314.0M global + 6.4M per thread (100 max threads)

[OK] Maximum possible memory usage: 950.7M (11% of installed RAM)

[OK] Slow queries: 0% (2K/2M)

[!!] Highest connection usage: 100% (101/100)

[OK] Key buffer size / total MyISAM indexes: 256.0M/7.2M

[OK] Key buffer hit rate: 99.9% (47M cached / 43K reads)

[OK] Query cache efficiency: 43.8% (472K cached / 1M selects)

[!!] Query cache prunes per day: 117870

[OK] Sorts requiring temporary tables: 0% (3 temp sorts / 191K sorts)

[!!] Temporary tables created on disk: 37% (72K on disk / 194K total)

[OK] Thread cache hit rate: 97% (2K created / 111K connections)

[!!] Table cache hit rate: 0% (251 open / 498K opened)

[OK] Open file limit used: 27% (284/1K)

[OK] Table locks acquired immediately: 98% (1M immediate / 1M locks)

[!!] Connections aborted: 6%

[OK] InnoDB data size / buffer pool: 1.3M/8.0M

-------- Recommendations -----------------------------------------------------

General recommendations:

Run OPTIMIZE TABLE to defragment tables for better performance

Enable the slow query log to troubleshoot bad queries

Reduce or eliminate persistent connections to reduce connection usage

When making adjustments, make tmp_table_size/max_heap_table_size equal

Reduce your SELECT DISTINCT queries without LIMIT clauses

Increase table_cache gradually to avoid file descriptor limits

Your applications are not closing MySQL connections properly

Variables to adjust:

max_connections (> 100)

wait_timeout (< 28800)

interactive_timeout (< 28800)

query_cache_size (> 32M)

tmp_table_size (> 32M)

max_heap_table_size (> 16M)

table_cache (> 256)

Вижу что конфиги немного править нужно.