Khóa phiên sau khi sử dụng Cm_RedisSession


9

Chúng tôi đã chuyển sang Redis làm Lưu trữ phiên với Mô-đun Cm_RedisSession mặc định từ Magento 1.9.2.4. Sau khi triển khai, rất nhiều Khách hàng đã trải qua thời gian tải trang rất dài (> 20-30 giây). Đối với Redis-Server, chúng tôi đang sử dụng AWS ElastiCache (m3.large)
Trong Tideways (tương tự Newrelic) Tôi đã thấy nút cổ chai này trong dấu vết:

Dấu vết từ Tideways

Sau khi đọc thêm về vấn đề này và xem xét nhật ký Cm_RedisSession, tôi nhận ra rằng Phiên từ Khách hàng đã bị khóa và sau khi nghiên cứu thêm, tôi quyết định nâng cấp Cm_RedisSession lên 1.14, vì những cải tiến cho việc khóa phiên.

Với Phiên bản mới nhất, sự cố được giảm thiểu, vì khóa sẽ bị hỏng ngay sau 5 giây. Nhưng vẫn còn thời gian tải là 5 giây.

Tôi đã có hai lý thuyết.

  1. Một số yêu cầu chết vì vậy không có session_close()cuộc gọi và vì lý do đó, khóa sẽ không được phát hành:

    Tôi đã bật mọi nhật ký (php-fpm, nginx và magento) và xem chúng cho đến khi lỗi này xuất hiện trong Tideways cho Khách hàng, nhưng không có lỗi trong khung thời gian cụ thể này

  2. Nhiều tập lệnh cố gắng đọc / ghi cùng một phiên:

    Tôi đã tạo một Tập lệnh gọi song song hàng trăm lần cùng một trang với cùng một cookie frontend, nhưng không có khóa nào xuất hiện.

Tại thời điểm này, tôi không thể hiểu tại sao khóa này xuất hiện và thậm chí tệ hơn, tôi không thể sao chép nó trên Maschine hoặc Hệ thống dàn địa phương của mình.

Có ai có một gợi ý hoặc giải pháp làm thế nào tôi có thể giải quyết vấn đề này?

Chỉnh sửa : ai đó đã cố gắng vô hiệu hóa khóa trong Cm_RedisSession?

Chỉnh sửa : cùng một vấn đề với 1.15

Chỉnh sửa : hầu hết các yêu cầu có khóa là yêu cầu ajax. Nhưng dù sao tôi cũng không thể tái tạo nó.


$ 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

tệp địa phương

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

INFOMàn hình Redis :

$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 được bao gồm trong mã lõi Magento 1.9.x nhưng thực sự được phát triển bởi Colin Mollenhour. Bạn có đang sử dụng mã mô-đun Cm_RedisSession đi kèm với 1.9.2.4 hoặc phiên bản mới nhất từ ​​GitHub github.com/colinmollenhour/Cm_RedisSession ?
ngủ

Như tôi đã viết, chúng tôi đã nâng cấp lên Phiên bản mới nhất
Pawel

Bạn có thấy cùng một vấn đề nếu bạn chạy các máy chủ redis tại địa phương
PAJ

1
Tôi đang theo dõi chính xác cùng một vấn đề. Chúng tôi lần đầu tiên trải nghiệm MemCache này và chuyển đến Redis với hy vọng đạt được nhiều khả năng hiển thị hơn. Chúng tôi đang sử dụng 1.14.2 với Apache 2.x. Sử dụng màn hình redis-cli tôi đã có thể xác định rằng các yêu cầu đang khóa phiên và sau đó không mở khóa. Chúng tôi vẫn chưa xác định lý do tại sao một tỷ lệ nhỏ các yêu cầu của chúng tôi thực hiện điều này (khoảng 50-100 mỗi giờ trong giờ cao điểm trong ngày).
Craig Harris

1
magento.stackexchange.com/a/130691/69 Một câu hỏi tương tự nhưng có thể cung cấp một số tùy chọn / công cụ để sử dụng khi gỡ lỗi.
B00mer

Câu trả lời:


6

Tôi dường như đã loại bỏ hầu hết các vấn đề của chúng tôi. Tuy nhiên, tôi không bao giờ thực sự xác định nguyên nhân chính xác.

Sau khi nâng cấp phiên bản mới nhất của Cm_RedisSession, việc ghi nhật ký chỉ ra rằng 95% các yêu cầu đang giữ phiên nên thực sự không trạng thái. Tôi đã triển khai FLAG_NO_START_SESSION trong preDispatch () để ngăn phiên tạo Magento. Tôi đã rất ngạc nhiên khi thấy rằng trong sản xuất, các yêu cầu "không trạng thái" hiện vẫn đang giữ 95% các khóa phiên. Điều tra sâu hơn cho thấy chúng tôi có một số nhà quan sát đang nổ súng vẫn đang cố gắng bắt đầu phiên. Khi những điều này đã được cập nhật để tôn vinh FLAG_NO_START_SESSION, vấn đề khóa phiên của chúng tôi đã gần như được xóa hoàn toàn.

Tôi không nghĩ rằng điều này giải quyết vấn đề, nhưng tôi hy vọng những người khác có thể sử dụng một kỹ thuật tương tự.


Tôi nghĩ rằng yêu cầu không trạng thái không hoạt động đối với chúng tôi, vì yêu cầu này cần phiên.
Pawel
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.