LINUX.ORG.RU

Redis сначала работает прекрасно, но потом дико тормозит 100% CPU!

 , ,


2

2

Рэдис использую как кэш временный на 1 день, без сохранения снапшотов. Сайт с посещаемостью от 50к. Изначально запускаю редис и он работает быстро - так как и нужно, но потом где-то через час он упирается в 100% CPU и начинает ниистово тормозить. Перезапускаю - и он снова работает великолепно. Слышал о том что это возможно из-за ключей удалённых какой-то мусор накапливается… Незнаю куда двигаться.

Server

redis_version:5.0.0 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:589bbec69921e7d1 redis_mode:standalone os:Linux 4.4.0-142-generic x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:5.4.0 process_id:10690 run_id:2bf978f1c4ac625d6f476055026dee521a6e2be6 tcp_port:6379 uptime_in_seconds:633 uptime_in_days:0 hz:10 configured_hz:10 lru_clock:6720524 executable:/root/redis-server config_file:/etc/redis/redis.conf

Clients

connected_clients:7 client_recent_max_input_buffer:215082 client_recent_max_output_buffer:102496 blocked_clients:0

Memory

used_memory:626516840 used_memory_human:597.49M used_memory_rss:619220992 used_memory_rss_human:590.54M used_memory_peak:626679184 used_memory_peak_human:597.65M used_memory_peak_perc:99.97% used_memory_overhead:5102146 used_memory_startup:791928 used_memory_dataset:621414694 used_memory_dataset_perc:99.31% allocator_allocated:627069472 allocator_active:649281536 allocator_resident:657899520 total_system_memory:16826458112 total_system_memory_human:15.67G used_memory_lua:13079552 used_memory_lua_human:12.47M used_memory_scripts:3805152 used_memory_scripts_human:3.63M number_of_cached_scripts:7252 maxmemory:1200000000 maxmemory_human:1.12G maxmemory_policy:allkeys-lru allocator_frag_ratio:1.04 allocator_frag_bytes:22212064 allocator_rss_ratio:1.01 allocator_rss_bytes:8617984 rss_overhead_ratio:0.94 rss_overhead_bytes:18446744073670873088 mem_fragmentation_ratio:0.99 mem_fragmentation_bytes:18446744073702256816 mem_not_counted_for_evict:0 mem_replication_backlog:0 mem_clients_slaves:0 mem_clients_normal:151170 mem_aof_buffer:0 mem_allocator:jemalloc-5.1.0 active_defrag_running:0 lazyfree_pending_objects:0

Persistence

loading:0 rdb_changes_since_last_save:21619 rdb_bgsave_in_progress:0 rdb_last_save_time:1550223763 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:-1 rdb_current_bgsave_time_sec:-1 rdb_last_cow_size:0 aof_enabled:0 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:-1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_last_write_status:ok aof_last_cow_size:0

Stats

total_connections_received:3976 total_commands_processed:28536173 instantaneous_ops_per_sec:70602 total_net_input_bytes:553074494 total_net_output_bytes:102416450 instantaneous_input_kbps:887.71 instantaneous_output_kbps:58.73 rejected_connections:0 sync_full:0 sync_partial_ok:0 sync_partial_err:0 expired_keys:0 expired_stale_perc:0.00 expired_time_cap_reached_count:0 evicted_keys:0 keyspace_hits:28500429 keyspace_misses:2099 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:0 migrate_cached_sockets:0 slave_expires_tracked_keys:0 active_defrag_hits:0 active_defrag_misses:0 active_defrag_key_hits:0 active_defrag_key_misses:0

Replication

role:master connected_slaves:0 master_replid:0c163b3898c1ce935bbf4a1938a635c22422c5f2 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0

CPU

used_cpu_sys:3.392000 used_cpu_user:71.864000 used_cpu_sys_children:0.000000 used_cpu_user_children:0.000000

Cluster

cluster_enabled:0

Keyspace

db0:keys=7209,expires=0,avg_ttl=0


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

Ну и элементарное: он вообще должен отрабатывать такую нагрузку на таком сервере?

ya-betmen ★★★★★ ()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от deep-purple

Опять валит по 100% и вот лог

21319:M 15 Feb 2019 11:02:25.887 # User requested shutdown... 21319:M 15 Feb 2019 11:02:25.887 * Removing the pid file. 21319:M 15 Feb 2019 11:02:25.887 # Redis is now ready to exit, bye bye... 25284:C 15 Feb 2019 11:02:32.710 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 25284:C 15 Feb 2019 11:02:32.710 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=25284, just started 25284:C 15 Feb 2019 11:02:32.710 # Configuration loaded 25285:M 15 Feb 2019 11:02:32.712 * Increased maximum number of open files to 10032 (it was originally set to 1024). _._ _.-``__ "-._ _.-`` `. `_. "-._ Redis 5.0.0 (00000000/0) 64 bit .-`` .-```. ```\/ _.,_ "-._ ( ' , .-` | `, ) Running in standalone mode |`-._`-...-` __...-.``-._|'` _.-'| Port: 6379 | `-._ `._ / _.-' | PID: 25285 `-._ `-._ `-./ _.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | http://redis.io `-._ `-._`-.__.-'_.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | `-._ `-._`-.__.-'_.-' _.-' `-._ `-.__.-' _.-' `-._ _.-' `-.__.-'

25285:M 15 Feb 2019 11:02:32.714 # Server initialized 25285:M 15 Feb 2019 11:02:32.714 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. 25285:M 15 Feb 2019 11:02:32.714 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled. 25285:M 15 Feb 2019 11:02:32.714 * Ready to accept connections

taram ()
Ответ на: комментарий от nikolnik

31408:M 15 Feb 2019 14:31:24.345 * Increased maximum number of open files to 100032 (it was originally set to 1024).

Только один в запуске остался, с ним ещё борюсь. Много как пробовал пофиксить, пока без результата.

taram ()

1. Из libastral — у тебя памяти не хватает.

2. Давай подробнее, сколько и каких запросов, что пишешь, что читаешь.. иначе это гадание на кофейной гуще.

kardapoltsev ★★ ()
Ответ на: комментарий от taram

да. если не хочешь писать много кода, то настрой репликацию между ними (что-то всё равно придётся написать — чтобы ходили на оба по какой-то очереди). я так неоднократно тушил пожары с внезапным ростом нагрузки. работает.

anonymous ()
Ответ на: комментарий от anonymous

тем не менее, на все твои вопросы ответы даны прямо в оп-посте

Да это мода такая: пришел - сделал вид что разбираешься - попросил логи - замолчал.

anonymous ()
Ответ на: комментарий от cdshines

slowlog get 1

    1. (integer) 240084
    2. (integer) 1550258355
    3. (integer) 64940
      1. «EVAL»
      2. «local allpks=redis.call(‘LRANGE’,‘page’,0,-1)\nlocal pks={}\nlocal n=0\nlocal v=nil\nlocal i=0\nlocal key=‘page’\nfor k,pk in ipairs(a… (264 more bytes)»
      3. «0»
    4. «127.0.0.1:42866»
    5. ""
anonymous ()
Ответ на: комментарий от kardapoltsev

1)У меня оперативы много. я пробовал выделять и больше 10гб оперативы. Результат тот же. 2)ключ короткий, а значение - сериализованый объект с гугл апи (действительно солидных размеров) вот ещё часть логов slowlog get 6

    1. (integer) 260784
    2. (integer) 1550259941
    3. (integer) 95808
      1. «EVAL»
      2. «local allpks=redis.call(‘LRANGE’,‘page’,0,-1)\nlocal pks={}\nlocal n=0\nlocal v=nil\nlocal i=0\nlocal key=‘page’\nfor k,pk in ipairs(a… (264 more bytes)»
      3. «0»
    4. «127.0.0.1:46082»
    5. ""
    1. (integer) 260783
    2. (integer) 1550259941
    3. (integer) 90693
      1. «EVAL»
      2. «local allpks=redis.call(‘LRANGE’,‘page’,0,-1)\nlocal pks={}\nlocal n=0\nlocal v=nil\nlocal i=0\nlocal key=‘page’\nfor k,pk in ipairs(a… (251 more bytes)»
      3. «0»
    4. «127.0.0.1:46032»
    5. ""
    1. (integer) 260782
    2. (integer) 1550259941
    3. (integer) 98237
      1. «EVAL»
      2. «local allpks=redis.call(‘LRANGE’,‘page’,0,-1)\nlocal pks={}\nlocal n=0\nlocal v=nil\nlocal i=0\nlocal key=‘page’\nfor k,pk in ipairs(a… (271 more bytes)»
      3. «0»
    4. «127.0.0.1:46092»
    5. ""
    1. (integer) 260781
    2. (integer) 1550259941
    3. (integer) 20511
      1. «EVAL»
      2. «local allpks=redis.call(‘LRANGE’,‘page’,0,-1)\nlocal pks={}\nlocal n=0\nlocal v=nil\nlocal i=0\nlocal key=‘page’\nfor k,pk in ipairs(a… (245 more bytes)»
      3. «0»
    4. «127.0.0.1:46134»
    5. ""
    1. (integer) 260780
    2. (integer) 1550259941
    3. (integer) 89580
      1. «EVAL»
      2. «local allpks=redis.call(‘LRANGE’,‘page’,0,-1)\nlocal pks={}\nlocal n=0\nlocal v=nil\nlocal i=0\nlocal key=‘page’\nfor k,pk in ipairs(a… (251 more bytes)»
      3. «0»
    4. «127.0.0.1:46004»
    5. ""
    1. (integer) 260779
    2. (integer) 1550259941
    3. (integer) 90584
      1. «EVAL»
      2. «local allpks=redis.call(‘LRANGE’,‘page’,0,-1)\nlocal pks={}\nlocal n=0\nlocal v=nil\nlocal i=0\nlocal key=‘page’\nfor k,pk in ipairs(a… (259 more bytes)»
      3. «0»
    4. «127.0.0.1:46122»
    5. ""
taram ()
Ответ на: комментарий от taram

использует EVAL в каждом запросе
использует LRANGE по огромному листу (я же правильно понял, что у тебя все засунуто в лист page?)
удивляется, что все тормозит

iSage ★★★★ ()
Ответ на: комментарий от kardapoltsev

Простейшее использование сохранить - извлечь. Никаких процедур и скриптов.

сейчас снизил лимит maxmemory 800 000 000 (800 мегабайт), нагрузка не вылезает под 100% CPU и держится на уровне до 55% и работает быстро. … Возможно поиск по всей базе просто не успевал проходить, пока я не снизил её объём…

taram ()
Ответ на: комментарий от taram

сериализованый объект с гугл апи (действительно солидных размеров)

Это будет наверное оффтопом, но я под гугл ютуб апи юзал https://github.com/ideawu/ssdb , засовывал туда жсон и гонял базу в 0.5 Тб на дешевом железе, причем лимит озу был 10гб.

anonymous ()
Ответ на: комментарий от taram

а что за логика вообще там?

вслепую - разложи json на хеши или прикрути rejson.

только держи все объекты не в кв-парах, а в хеше: https://instagram-engineering.com/storing-hundreds-of-millions-of-simple-key-...

вообще lrange твой на каждый вызов - это фейспалм. можешь дешево сделать так: набор хешей типа `prefix:field_name {id => value}`, поиск по таким будет e.g. `hget prefix:name $NAME`.

cdshines ★★★★ ()
Последнее исправление: cdshines (всего исправлений: 2)
Ответ на: комментарий от taram

Ключевой ошибкой здесь было то что я не правильный тип данных использовал. И не правильно.

сейчас использую такой вариант и работает хорошо.

$result = $redis->executeCommand('hmset', ['test_collection', 'key1', 'val1', 'key2', 'val2']);

$result = $redis->executeCommand('hgetall', [$nameCache]); за 1 день про редис узнал вдоль и поперёк... Всем спасибо. Вопрос решён.

taram ()