SmartCJ Support Forum

В общем-то ни с того ни с сего. Не вижу причины... можете что-нибудь подсказать?
la 20-40, idle проца 0
на сервере 8 смартсиджей,
из них 7 на одной базе (1мастер+6), 45к тумб, трафа мало, по 1к на 5-ти, 3к на одном и 7 к на одном
и один отдельно, 206к тумб, на нем 5к трафа (грешу на этот, т.к. эффект торможения стал проявляться в процессе закачки туда тумб)...

Пробовал ставить таблицы rot_* в InnoDB, картина не меняется.

Кроны запускаются одновременно.

Сервер 4хядерный ДуалКсеон, 4 гига памяти

last pid: 84468; load averages: 22.93, 24.91, 20.85 up 105+11:11:17 21:22:04
280 processes: 31 running, 249 sleeping
CPU states: 66.5% user, 0.0% nice, 32.3% system, 1.1% interrupt, 0.0% idle
Mem: 1450M Active, 3823M Inact, 399M Wired, 173M Cache, 112M Buf, 165M Free
Swap: 2048M Total, 140K Used, 2048M Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
82783 mysql 85 96 0 386M 218M ucond 2 16:59 139.45% mysqld
83950 apache 1 20 0 89424K 17256K lockf 3 0:04 6.69% httpd
83958 apache 1 20 0 90780K 18760K lockf 0 0:03 4.84% httpd
84440 adult 1 108 0 32908K 25072K RUN 0 0:01 4.56% php
84108 apache 1 20 0 92364K 20400K lockf 0 0:04 4.40% httpd
83878 apache 1 20 0 90244K 18780K lockf 0 0:03 4.20% httpd
83926 apache 1 103 0 91132K 19188K CPU3 0 0:03 3.91% httpd
84435 adult 1 108 0 36616K 28588K RUN 3 0:01 3.59% php
83909 apache 1 20 0 90248K 19376K lockf 0 0:03 3.47% httpd
83923 apache 1 20 0 91036K 18688K lockf 3 0:02 3.42% httpd
83963 apache 1 20 0 89992K 18664K lockf 3 0:04 3.32% httpd
83892 apache 1 -7 0 92956K 21264K drainv 1 0:03 3.22% httpd
83885 apache 1 20 0 90492K 18484K lockf 0 0:02 2.44% httpd
84422 adult 1 108 0 33524K 25724K RUN 1 0:02 2.16% php
83946 apache 1 20 0 90788K 19160K lockf 0 0:03 2.05% httpd
83954 apache 1 20 0 90780K 19188K lockf 0 0:03 2.00% httpd
83948 apache 1 20 0 91036K 19296K lockf 0 0:03 1.86% httpd
83890 apache 1 20 0 89156K 17324K lockf 3 0:02 1.86% httpd
83876 apache 1 20 0 91288K 19436K lockf 3 0:03 1.81% httpd
84428 adult 1 108 0 35236K 27328K RUN 1 0:02 1.77% php
83898 apache 1 4 0 93340K 21376K sbwait 0 0:04 1.76% httpd

Я б начал смотреть что там 33% систем. Если б кушал только скрипт все было б в юзер, да и обычно выглядит типа 2% система, 30% юзер, те система много кушать не должна по идее.

Возможно на базе этого придут какие-то мысли дальше.

Единственное я не совсем уверен в юзер или систем идет прямая раздача контента когда например nginx использует системные ф-ции для чтения, стоит про это так же почитать.

может кому интересно, но проблема оказалась в кэше (кэш дефолтный)...
из-за какой-то свеженькой шизы то-ли с файловой системой, то-ли с привилегиями, кэш всё время обновлялся.
Ввиду большого объема кэша разбираться и чинить было не с руки, проще и надежней оказалось переставить кэширование на redis, после чего дефолтный кэш грохнуть.

Отлично, спасибо, думаю этот топик пригодится тем сомневается по поводу варнинга про new cache engines.

как-то я уже не уверен, что всё хорошо...
Какое-то время нагрузка была нормальная, но потом редискин файл dump.rdb перестал пополняться (т.е. уже часов 10 стоит без изменения), размером 37186 килобайт.
И нагрузка опять начала расти. Может есть какие-то идеи?

конфиг редиса:
daemonize yes
pidfile /var/run/redis/redis.pid
port 6379
bind 127.0.0.1
timeout 30
tcp-keepalive 0
loglevel warning
logfile /var/log/redis/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /usr/home/redis/
repl-disable-tcp-nodelay no
#slave-priority 100
maxmemory 512mb
maxmemory-policy volatile-lru
appendonly no
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes

Если в файле не меняется - видимо никто туда не пишет, а если не пишет - видимо редис не прописан в скрипте.

редис в скрипте прописан, конечно же
в /scj/include/config.php для каждой из 8 копий прописано
$config['redis_host'] = '127.0.0.1';
$config['redis_port'] = '6379';
$config['redis_database'] = 0; //тут разная цифра
$config['redis_password'] = '';

после добавления в очередную копию файл dump.rdb понемногу увеличивался, по паре мегабайт за раз, но в какой-то момент перестал. И уже сутки без изменений.

в /sch/cache/ скрипты больше ничего не пишут

но ощущение такое, что кэш работает только частично
судя по нагрузке, значительная часть страниц постоянно генерится.

помогла замена в конфиге редиса
maxmemory 512mb на maxmemory 2048mb
и его рестарт

Интересно куда тогда он писал в этот момент если файлы были по паре мег.

исходя из директивы stop-writes-on-bgsave-error yes очевидно, что никуда...
как только не удалось записать очередной ключ, просто перестал писать вообще.
Вообще, с этим редисом надо осторожнее... его настройка далеко не тривиальное занятие.