ProLiant

ProLiant
Рейтинг
249
Регистрация
07.12.2005

Ребята, вы реально пугаете. Я пошутил про сентябрь... А потом подумал: воображение у яндексоидов воспаленное, бурное, если додумались до "Калининграда", то почему бы не придумать "Сентябрь". :)

Alех,

1. Других форумов сегодня за день было открыто много, в т.ч. большее количество из них на аналогичном двиге... Все в порядке.

2. Стоит лицензионный обновляемый НОД + прогонял сегодня же сразу им - тишина... (

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

Но почему тогда только здесь? :)

Может уже было подобное? Сам не нахожу. Буду признателен, если ткнете носом.

Скорее всего очередной сбой на стороне яши. Общие факторы, не такие и общие получаются. У каждого по-разному. У кого-то с уником вылетели, у кого-то с некачественным рерайтом и т.п. Т.е. нет очевидных и одинаковых у всех факторов. У кого-то дроп, у кого-то нет...

П.с. У меня пока вроде все без изменений... Есть сайты как с уником, так и с копипастом грабером.

Какие-то удивительные алгоритмы фильтра. Ну дроп еще более-менее понятно, хотя тоже странно, но созданные именно в сентябре... Почему не в августе, не в октябре.

Это новый фильтр - "Сентябрь" называется.. ;)

ProLiant:
Что-то у меня вот такая ерунда начала вылазить:

Что-то не пойму.. Это у меня только такие глюки?

Что-то у меня вот такая ерунда начала вылазить:

[ATTACH]118723[/ATTACH]

[ATTACH]118724[/ATTACH]

Это откуда? :)

П.с. Опера. На других сайтах ничего не вылазит. )

jpg ser1.jpg
jpg ser2.jpg
Ошибка постоянно вылетает? Или "мигает"? При большом онлайне?

Постоянно. Но вчера еще на главную более-менее можно было зайти, а при попытке просмотреть новость была ошибка, а сегодня и на главной.. :(

попробуйте тюнер запустить
и вывод тюнера давайте сюда

Вот :

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

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 202M (Tables: 257)
[--] Data in MEMORY tables: 0B (Tables: 7)
[!!] Total fragmented tables: 4

-------- Security Recommendations -------------------------------------------
ERROR 1142 (42000) at line 1: SELECT command denied to user 'название базы'@'localhost' for table 'user'
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 50m 14s (243K q [36.842 qps], 21K conn, TX: 2B, RX: 43M)
[--] Reads / Writes: 85% / 15%
[--] Total buffers: 208.0M global + 7.2M per thread (500 max threads)
[!!] Maximum possible memory usage: 3.7G (191% of installed RAM)
[OK] Slow queries: 0% (7/243K)
[OK] Highest usage of available connections: 4% (21/500)
[OK] Key buffer size / total MyISAM indexes: 128.0M/109.5M
[OK] Key buffer hit rate: 99.2% (8M cached / 73K reads)
[OK] Query cache efficiency: 53.3% (87K cached / 164K selects)
[!!] Query cache prunes per day: 139319
[OK] Sorts requiring temporary tables: 0% (37 temp sorts / 39K sorts)
[!!] Joins performed without indexes: 1026
[!!] Temporary tables created on disk: 33% (9K on disk / 29K total)
[OK] Thread cache hit rate: 99% (21 created / 21K connections)
[OK] Table cache hit rate: 92% (594 open / 639 opened)
[OK] Open file limit used: 13% (1K/8K)
[OK] Table locks acquired immediately: 99% (120K immediate / 120K locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Reduce your overall MySQL memory footprint for system stability
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
query_cache_size (> 64M)
join_buffer_size (> 1.0M, or always use indexes with joins)
tmp_table_size (> 16M)
max_heap_table_size (> 16M)

П.с. На сервере, кроме этого сайта, есть и другие, на этом же двиге, с большей посещаемостью. В их работе никаких проблем сейчас.

admak:
попробуйте в файле /etc/my.cnf увеличить параметр max_allowed_packet

и перезапустите mysql

Было 16, увеличили до 32, не помогает.. (

warlock77, Согласен. Но и команда ведь почти постоянно здесь обитает и может сама отслеживать появление новых видов обмана.. :)

Yurecm, Действительно настолько подешевела?

И вопрос. Планируется ли добавить перелинковку?

Всего: 2596