Мы перешли на Redis в качестве хранилища сессий с модулем Cm_RedisSession по умолчанию из Magento 1.9.2.4. После развертывания многие клиенты испытывали очень длительное время загрузки страницы (> 20-30 сек.). Для Redis-Server мы используем AWS ElastiCache (m3.large).
В Tideways (по аналогии с Newrelic) я увидел это узкое место в следе:
Прочитав больше об этой проблеме и заглянув в журнал Cm_RedisSession, я выяснил, что сеанс от клиента был заблокирован, и после дополнительных исследований я решил обновить Cm_RedisSession до версии 1.14 из-за улучшений для блокировки сеанса.
В последней версии проблема сведена к минимуму, потому что блокировка теперь будет корректно ломаться через 5 секунд. Но время загрузки все равно составляет 5 секунд.
У меня было две теории.
Некоторые запросы умирают, поэтому
session_close()звонков нет, и по этой причине блокировка не будет снята:Я включил все журналы (php-fpm, nginx и magento) и наблюдал за ними, пока эта ошибка не появится в Tideways for Customer, но в этот конкретный период времени ошибки не было
Несколько сценариев пытаются читать / писать один и тот же сеанс:
Я создал скрипт, который вызывает сто раз параллельно одну и ту же страницу с одним и тем же внешним файлом cookie, но блокировка не появляется.
На данный момент, я не могу понять, почему этот замок появляется, и что еще хуже, я не могу воспроизвести его на моем локальном компьютере или системе подготовки.
У кого-нибудь есть подсказка или решение, как я мог решить эту проблему?
Изменить : кто-то пытался отключить блокировку в Cm_RedisSession?
Изменить : та же проблема с 1.15
Изменить : большинство запросов с блокировкой являются запросами ajax. Но я все равно не могу воспроизвести это.
$ php5-fpm -v
PHP 5.5.32-1+deb.sury.org~trusty+1 (fpm-fcgi) (built: Feb 5 2016 10:10:42)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies$ nginx -v
nginx version: nginx/1.8.1local.xml
<redis_session>
<host>***************</host>
<port>****</port>
<password></password>
<timeout>2.5</timeout>
<persistent></persistent>
<db>0</db>
<compression_threshold>2048</compression_threshold>
<compression_lib>gzip</compression_lib>
<log_level>1</log_level>
<max_concurrency>6</max_concurrency>
<break_after_frontend>5</break_after_frontend>
<break_after_adminhtml>30</break_after_adminhtml>
<first_lifetime>600</first_lifetime>
<bot_first_lifetime>60</bot_first_lifetime>
<bot_lifetime>7200</bot_lifetime>
<disable_locking>0</disable_locking>
<min_lifetime>60</min_lifetime>
<max_lifetime>2592000</max_lifetime>
</redis_session>Redis INFOScreen:
$1939
# Server
redis_version:2.8.24
redis_git_sha1:0
redis_git_dirty:0
redis_build_id:0
redis_mode:standalone
os:Amazon ElastiCache
arch_bits:64
multiplexing_api:epoll
gcc_version:0.0.0
process_id:1
run_id:fbf620d695c006bdb570c05b104404eb8f2c12aa
tcp_port:6379
uptime_in_seconds:1140502
uptime_in_days:13
hz:10
lru_clock:12531431
config_file:/etc/redis.conf
# Clients
connected_clients:8
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
# Memory
used_memory:2586086144
used_memory_human:2.41G
used_memory_rss:2637590528
used_memory_peak:2586312888
used_memory_peak_human:2.41G
used_memory_lua:36864
mem_fragmentation_ratio:1.02
mem_allocator:jemalloc-3.6.0
# Persistence
loading:0
rdb_changes_since_last_save:18525202
rdb_bgsave_in_progress:0
rdb_last_save_time:1471008721
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
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
# Stats
total_connections_received:1518441
total_commands_processed:28898066
instantaneous_ops_per_sec:14
total_net_input_bytes:7409376406
total_net_output_bytes:3059470870
instantaneous_input_kbps:3.10
instantaneous_output_kbps:0.78
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:420590
evicted_keys:0
keyspace_hits:8754547
keyspace_misses:18323
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
# Replication
role:master
connected_slaves:0
master_repl_offset:322498
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2795
repl_backlog_histlen:319704
# CPU
used_cpu_sys:729.42
used_cpu_user:509.25
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
# Keyspace
db0:keys=1413298,expires=1413297,avg_ttl=1780138273
Ответы:
Я, кажется, в основном устранил наши проблемы. Тем не менее, я никогда не определял точную причину.
После обновления последней версии Cm_RedisSession в журнале было указано, что 95% запросов, которые удерживали сеанс, должны быть фактически без сохранения состояния. Я реализовал FLAG_NO_START_SESSION в preDispatch (), чтобы предотвратить создание сеансов Magento. Я был очень удивлен, обнаружив, что в производственном процессе запросы «без сохранения состояния» все еще удерживают 95% блокировок сеанса. Дальнейшее расследование показало, что у нас было несколько наблюдателей, которые стреляли, которые все еще пытались начать сеанс. Как только они были обновлены, чтобы также соответствовать FLAG_NO_START_SESSION, наша проблема блокировки сеанса была почти полностью удалена.
Я не думаю, что это решает проблему, но я надеюсь, что другие могут использовать подобную технику.
источник