使用Cm_RedisSession之后的会话锁定

我们使用Magento 1.9.2.4中的默认Cm_RedisSession模块切换到Redis作为会话存储。部署后，许多客户经历了非常长的页面加载时间（> 20-30秒）。对于Redis-Server，我们在Tideways中使用AWS ElastiCache（m3.large）
（类似于Newrelic），在跟踪中看到了这个瓶颈：

在阅读了有关此问题的更多信息并查看了Cm_RedisSession日志后，我发现来自客户的会话已被锁定，并且经过更多研究后，由于会话锁定的改进，我决定将Cm_RedisSession升级到1.14。

使用最新版本，该问题已最小化，因为该锁定现在将在5秒后正确断开。但是仍然有5秒的加载时间。

我有两种理论。

1. 一些请求死亡，因此没有任何session_close()调用，因此该锁将不会被释放：

   我启用了每个日志（php-fpm，nginx和magento），并看着它们，直到该错误在Tideways中出现给客户，但在此特定时间范围内没有错误

2. 多个脚本尝试读取/写入同一会话：

   我创建了一个脚本，该脚本使用相同的前端cookie并行调用同一页面一百次，但是没有出现锁。

在这一点上，我不知道为什么会出现此锁，更糟糕的是，我无法在本地的Maschine或登台系统上重现它。

有没有人暗示或解决我该如何解决这个问题？

编辑：有人试图禁用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.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>

Redis 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

我似乎基本上消除了我们的问题。但是，我从未真正确定确切原因。

升级最新版本的Cm_RedisSession后，日志记录表明，持有该会话的95％的请求实际上应该是无状态的。我在preDispatch（）中实现了FLAG_NO_START_SESSION，以防止Magento创建会话。我很惊讶地发现，在生产中，现在的“无状态”请求仍然持有95％的会话锁。进一步调查发现，我们有一些正在解雇的观察员仍在尝试开始会议。一旦对它们进行了更新，使它们也符合FLAG_NO_START_SESSION的要求，我们的会话锁定问题将几乎全部消除。

我认为这不能解决问题，但希望其他人也可以使用类似的技术。