это вводим по 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)
Вижу что конфиги немного править нужно.
Не совсем понял что нужно сделать.
Странно, обычно при платном добавлении ответ приходит от 1 до 7 дней.
Наш местный самарский системный администратор, разговорился с ним вчера. он как раз и выявил мне неисправность жестких дисков.
Подробнее можно?
Некоторые ошибки уже исправлял ранее.
Когда то был еще некорректно удален модуль галереи, в панели гугл вебмастер до сих пор иногда ссылки какие то пишутся.
Ну а как тогда правильнее, завершать зависшие процессы по ssh?
Откройте исходный код страницы своего профиля, и посмотрите возможно прописано следующее:
<meta name="robots" content="noindex,nofollow" />
Я обычно закрываю ненужные страниц от индексации именно таким образом.
Достаточно.
Это дубль страницы или просто ненужная страница?
Реклама яндекс директа на добавление точно не влияет, адсенс под вопросом.
С орфографическими ошибками согласен, боремся, просто сложно сразу столько статей обработать.
Сейчас 8 Гб памяти, но как и писал выше после 3-5 дней работы сервера расход памяти 5-6 Гб из 8Гб.
При этом доп модулей к движку не прикручено, а запросов к базе данных всего 3-4 на страницу.
Расход памяти на генерацию 1 страницы составляет от 3 до 5 мб.---------- Добавлено 28.01.2013 в 18:46 ----------
Под грамотным кеширование на dle наверное подразумевается использование memcache?
У меня используется файловый кеш.---------- Добавлено 28.01.2013 в 18:49 ----------
Надо почитать об этом подробнее.
