Cm_RedisSession ব্যবহারের পরে সেশন লক করুন


9

আমরা ম্যাজেন্টো ১.৯.২.৪ থেকে ডিফল্ট সিএম_রেডিসেশন মডিউলটি দিয়ে সেশন স্টোরেজ হিসাবে রেডিসে স্যুইচ করেছি। স্থাপনার পরে প্রচুর গ্রাহক খুব দীর্ঘ পৃষ্ঠার লোড বার (> 20-30 সেকেন্ড) অনুভব করেছিলেন experienced রেডিস-সার্ভারের জন্য আমরা অ্যাডাব্লুএস এলাস্টি ক্যাশে (এম 3.লাজ) টাইডওয়েতে (নিউরেলিকের সমান) ব্যবহার করছি
আমি ট্রেসটিতে এই বাধাটি দেখেছি:

টাইডওয়েস থেকে ট্রেস করুন

এই সমস্যাটি সম্পর্কে আরও পড়ার পরে এবং Cm_RedisSession লগটি সন্ধান করার পরে, আমি বুঝতে পারলাম যে গ্রাহকের কাছ থেকে সেশনটি লক হয়েছে এবং আরও গবেষণার পরে আমি সিদ্ধান্ত নিয়েছি যে সেশন লক করার ক্ষেত্রে উন্নতি হয়েছে সে কারণে সিএম_প্রিজিকেশনটি 1.14 এ আপগ্রেড করব।

সর্বশেষতম সংস্করণে সমস্যাটি হ্রাস করা হয়েছে, কারণ লকটি এখন 5 সেকেন্ড পরে সঠিকভাবে ভেঙে যাবে। তবে এখনও 5 সেকেন্ডের একটি লোডটাইম রয়েছে।

আমার দুটি তত্ত্ব ছিল।

  1. কিছু অনুরোধ মারা যায় তাই কোনও session_close()কল নেই এবং সেই কারণে লকটি প্রকাশ করা হবে না:

    আমি প্রতিটি লগ সক্ষম করেছি (পিএইচপি-এফএম, এনগিনেক্স এবং ম্যাজেন্টো) এবং কোনও গ্রাহকের জন্য টাইডওয়েতে এই ত্রুটিটি উপস্থিত না হওয়া পর্যন্ত এগুলি পর্যবেক্ষণ করেছি, তবে এই নির্দিষ্ট সময়সীমার কোনও ত্রুটি ছিল না until

  2. একাধিক স্ক্রিপ্ট একই অধিবেশনটি পড়ার / লেখার চেষ্টা করে:

    আমি একটি স্ক্রিপ্ট তৈরি করেছি যা একই পৃষ্ঠার সমানতালে একই পৃষ্ঠার অনুরূপ কুকি সহ কল ​​করে, তবে কোনও লক উপস্থিত হয় না।

এই মুহুর্তে, আমি কেন বুঝতে পারি না কেন এই লকটি প্রদর্শিত হয় এবং আরও খারাপ, আমি এটি আমার স্থানীয় মাসচাইন বা মঞ্চায়ন সিস্টেমে পুনরুত্পাদন করতে পারি না।

আমি কীভাবে এই সমস্যাটি সমাধান করতে পারি তার কোনও ইঙ্গিত বা সমাধান রয়েছে?

সম্পাদনা : কেউ কি সিএম_রিডিসেসনে লকটি অক্ষম করার চেষ্টা করেছিল?

সম্পাদনা করুন : 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

gin 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
সিএম_রিডিসসেশনটি ম্যাজেন্টো 1.9.x কোর কোডে অন্তর্ভুক্ত করা হয়েছে তবে এটি কলিন মোলেনহুর দ্বারা নির্মিত actually আপনি কি 1.9.2.4 এর সাথে অন্তর্ভুক্ত Cm_RedisSession মডিউল কোড ব্যবহার করছেন বা GitHub github.com/colinmollenhour/Cm_RedisSession এর সর্বশেষতম সংস্করণ ব্যবহার করছেন ?
পাজ

আমি যেমন লিখেছি, আমরা সর্বশেষ সংস্করণে আপগ্রেড করেছি
পাভেল

যদি আপনি স্থানীয়ভাবে redis সার্ভার চালানোর আপনি একই সমস্যা দেখতে না
paj

1
আমি ঠিক একই সমস্যাটি সন্ধান করছি। আমরা প্রথমে এই মেমকেচেটি অভিজ্ঞতা পেয়েছি এবং আরও দৃশ্যমানতা পাওয়ার আশায় রেডিসে চলে এসেছি। আমরা অ্যাপাচি ২.x এর সাথে 1.14.2 ব্যবহার করছি। রেডিস-ক্লাইম মনিটর ব্যবহার করে আমি সনাক্ত করতে সক্ষম হয়েছি যে অনুরোধগুলি সেশনটি লক করছে এবং তারপরে এটি আনলক করা হচ্ছে না। আমরা এখনও নির্ধারিত হইনি যে আমাদের অনুরোধের একটি অল্প শতাংশ কেন এটি করে (দিনের শীর্ষ সময়কালে প্রায় 50-100 ঘন্টা)।
ক্রেগ হ্যারিস

1
magento.stackexchange.com/a/130691/69 একটি অনুরূপ প্রশ্ন কিন্তু ডিবাগ করার সময় কিছু বিকল্প / সরঞ্জাম প্রস্তাব করতে পারে।
B00MER

উত্তর:


6

আমি বেশিরভাগই আমাদের সমস্যাগুলি মুছে ফেলেছি বলে মনে হয়। যাইহোক, আমি কখনই সঠিক কারণটি নির্ধারণ করতে পারি নি।

Cm_RedisSession এর সর্বশেষতম সংস্করণটি আপগ্রেড করার পরে লগিং সূচিত করেছে যে অধিবেশনটির 95% অনুরোধগুলি আসলে রাষ্ট্রহীন হওয়া উচিত। আমি ম্যাজেন্টো সেশন তৈরি করতে বাধা দিতে প্রিডিস্প্যাচ () এ FLAG_NO_START_SESSION প্রয়োগ করেছি। আমি খুব অবাক হয়েছিলাম যে উত্পাদনে এখন "রাষ্ট্রবিহীন" অনুরোধগুলি এখনও 95% সেশন লক ধরে আছে। আরও তদন্তে দেখা গেছে যে আমাদের এমন কিছু পর্যবেক্ষক ছিল যা গুলি চালাচ্ছিল যা অধিবেশন শুরু করার চেষ্টা করছিল। এগুলি একবার FLAG_NO_START_SESSION কে সম্মানের জন্য আপডেট করা হলে আমাদের সেশন লকিংয়ের বিষয়টি প্রায় পুরোপুরি সরিয়ে দেওয়া হয়েছে।

আমি মনে করি না যে এটি সমস্যার সমাধান করে, তবে আমি আশা করি অন্যরাও অনুরূপ কৌশল ব্যবহার করতে সক্ষম হবেন।


আমি মনে করি রাষ্ট্রবিহীন অনুরোধ অনুরোধটি আমাদের পক্ষে কাজ করে না, কারণ এই অনুরোধগুলির অধিবেশনটি প্রয়োজন।
পাভেল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.