Cm_RedisSession 사용 후 세션 잠금


9

Magento 1.9.2.4의 기본 Cm_RedisSession 모듈을 사용하여 Redis를 세션 저장소로 전환했습니다. 배포 후 많은 고객이 매우 긴 페이지로드 시간 (> 20-30 초)을 경험했습니다. Redis-Server의 경우 AWS ElastiCache (m3.large)를
Tideways (Newrelic과 유사)에서 사용하고 있습니다.

조수에서 추적

이 문제에 대해 자세히 읽고 Cm_RedisSession 로그를 살펴본 후 고객의 세션이 잠겨 있음을 확인한 후 더 많은 연구를 한 후 세션 잠금 기능이 향상되어 Cm_RedisSession을 1.14로 업그레이드하기로 결정했습니다.

최신 버전에서는 5 초 후에 잠금이 올바르게 끊어지기 때문에 문제가 최소화됩니다. 그러나 여전히로드 시간은 5 초입니다.

두 가지 이론이있었습니다.

  1. 일부 요청은 종료되므로 session_close()호출 이 없으므로 잠금이 해제되지 않습니다.

    모든 로그 (php-fpm, nginx 및 magento)를 활성화하고 Tideways for Customer (고객의 Tideways)에이 오류가 표시 될 때까지이 로그를 보았지만이 특정 시간대에는 오류가 없었습니다.

  2. 여러 스크립트가 동일한 세션을 읽거나 쓰려고합니다.

    동일한 프론트 엔드 쿠키를 사용하여 동일한 페이지를 수백 번 병렬로 호출하는 스크립트를 만들었지 만 잠금이 나타나지 않습니다.

이 시점 에서이 잠금이 나타나는 이유를 알 수 없으며 로컬 Maschine 또는 스테이징 시스템 에서이 잠금을 재현 할 수 없습니다.

아무도이 문제를 해결할 수있는 힌트 나 해결책이 있습니까?

편집 : 누군가 Cm_RedisSession에서 잠금을 해제하려고 했습니까?

편집 : 1.15와 동일한 문제

편집 : 잠금이있는 대부분의 요청은 아약스 요청입니다. 그러나 어쨌든 그것을 재생할 수 없습니다.


$ 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.1

local.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>

레디 스 INFO화면 :

$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

1
Cm_RedisSession은 Magento 1.9.x 핵심 코드에 포함되어 있지만 실제로 Colin Mollenhour가 개발했습니다. 1.9.2.4 또는 GitHub github.com/colinmollenhour/Cm_RedisSession 의 최신 버전에 포함 된 Cm_RedisSession 모듈 코드를 사용하고 있습니까?
paj

내가 쓴 것처럼, 우리는 최신 버전으로 업그레이드했습니다
Pawel

redis 서버를 로컬로 실행하면 동일한 문제가 발생
합니까

1
나는 정확히 같은 문제를 추적하고 있습니다. 우리는이 MemCache를 처음 경험하고 더 많은 가시성을 얻기 위해 Redis로 옮겼습니다. Apache 2.x와 함께 1.14.2를 사용하고 있습니다. redis-cli 모니터를 사용하여 요청이 세션을 잠그고 잠금을 해제하지 않는 것을 확인할 수있었습니다. 우리는 여전히 요청의 적은 비율이 왜 그렇게하는지 결정하지 못했습니다 (성수기에는 시간당 약 50-100).
Craig Harris

1
magento.stackexchange.com/a/130691/69 비슷한 질문이지만 디버깅 할 때 사용할 몇 가지 옵션 / 도구가 제공 될 수 있습니다.
B00MER

답변:


6

나는 우리의 문제를 대부분 해결 한 것으로 보인다. 그러나 나는 실제로 정확한 원인을 결정하지 못했습니다.

최신 버전의 Cm_RedisSession을 업그레이드 한 후 로깅은 세션을 보유한 요청의 95 %가 실제로 상태가 없음을 나타냅니다. preagent ()에서 FLAG_NO_START_SESSION을 구현하여 Magento가 세션을 만들지 못하게했습니다. 프로덕션에서 현재 "상태 비 저장"요청이 여전히 세션 잠금의 95 %를 보유하고 있다는 사실에 매우 놀랐습니다. 추가 조사에 따르면 우리는 여전히 세션을 시작하려고 시도하는 일부 관측자가 있음을 발견했습니다. FLAG_NO_START_SESSION을 준수하도록 업데이트 된 세션 잠금 문제는 거의 완전히 제거되었습니다.

이것이 문제를 해결한다고 생각하지는 않지만 다른 사람들이 비슷한 기술을 사용할 수 있기를 바랍니다.


이 요청에는 세션이 필요하기 때문에 상태 비 저장 요청 요청이 작동하지 않는다고 생각합니다.
Pawel
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.