หลีกเลี่ยงการสลับกับ ElastiCache Redis

เราประสบปัญหาอย่างต่อเนื่องกับการสลับอินสแตนซ์ ElastiCache Redis ของเรา ดูเหมือนว่า Amazon จะมีการตรวจสอบภายในที่ไม่แน่นอนซึ่งแจ้งให้ทราบถึงการสลับการใช้งานและเพียงแค่รีสตาร์ทอินสแตนซ์ ElastiCache (ดังนั้นจึงสูญเสียรายการแคชทั้งหมดของเรา) นี่คือแผนภูมิของ BytesUsedForCache (สายสีน้ำเงิน) และ SwapUsage (เส้นสีส้ม) ในอินสแตนซ์ ElastiCache ของเราในช่วง 14 วันที่ผ่านมา:

Redis ElastiCache BytesUsedForCache และ Swap

คุณสามารถดูรูปแบบของการใช้งาน swap ที่เพิ่มขึ้นซึ่งดูเหมือนว่าจะกระตุ้นการรีบู๊ตอินสแตนซ์ ElastiCache ของเราซึ่งเราสูญเสียรายการแคชทั้งหมดของเรา (BytesUsedForCache ลดลงเป็น 0)

แท็บ 'เหตุการณ์แคช' ของแดชบอร์ด ElastiCache ของเรามีรายการที่เกี่ยวข้อง:

รหัสที่มา | ประเภท | วันที่ | เหตุการณ์

cache-instance-id | แคชคลัสเตอร์ อ. ก.ย. 22 07:34:47 GMT-400 2015 | โหนดแคช 0001 รีสตาร์ท

cache-instance-id | แคชคลัสเตอร์ อ. ก.ย. 22 07:34:42 GMT-400 2015 | เกิดข้อผิดพลาดในการรีสตาร์ทเอ็นจินแคชในโหนด 0001

cache-instance-id | แคชคลัสเตอร์ อาทิตย์ 20 กันยายน 11:13:05 GMT-400 2015 | โหนดแคช 0001 รีสตาร์ท

cache-instance-id | แคชคลัสเตอร์ พ.ย. 17 22:59:50 GMT-400 2015 | โหนดแคช 0001 รีสตาร์ท

cache-instance-id | แคชคลัสเตอร์ พุธ Sep 16 10:36:52 GMT-400 2015 | โหนดแคช 0001 รีสตาร์ท

cache-instance-id | แคชคลัสเตอร์ อังคาร 15 ก.ย. , 05:02:35 GMT-400 2015 | โหนดแคช 0001 รีสตาร์ท

(snip รายการก่อนหน้า)

อเมซอนอ้างว่า :

SwapUsage - ในการใช้งานปกติ Memcached หรือ Redis ไม่ควรทำการสลับ

การตั้งค่าที่เกี่ยวข้อง (ไม่ใช่ค่าเริ่มต้น) ของเรา:

ประเภทอินสแตนซ์: cache.r3.2xlarge
maxmemory-policy: allkeys-lru (เราใช้ค่าเริ่มต้นระเหย -lru ก่อนหน้านี้โดยไม่แตกต่างกันมาก)
maxmemory-samples: 10
reserved-memory: 2500000000
ตรวจสอบคำสั่ง INFO ในอินสแตนซ์ที่ฉันเห็นmem_fragmentation_ratioระหว่าง 1.00 และ 1.05

เราได้ติดต่อฝ่ายสนับสนุน AWS และไม่ได้รับคำแนะนำที่เป็นประโยชน์มาก: พวกเขาแนะนำให้ใช้หน่วยความจำสำรองที่เพิ่มมากขึ้น (ค่าเริ่มต้นคือ 0 และเรามีการจอง 2.5 GB) เราไม่มีการจำลองแบบหรือสแนปชอตที่ตั้งค่าไว้สำหรับอินสแตนซ์แคชนี้ดังนั้นฉันเชื่อว่าไม่มี BGSAVE ที่ควรจะเกิดขึ้นและทำให้เกิดการใช้หน่วยความจำเพิ่มเติม

maxmemoryหมวกของ cache.r3.2xlarge เป็น 62495129600 ไบต์และแม้ว่าเราจะตีหมวกของเรา (ลบของเราreserved-memory) อย่างรวดเร็วก็ดูเหมือนว่าแปลกกับผมว่าโฮสต์ระบบปฏิบัติการจะรู้สึกกดดันที่จะใช้แลกเปลี่ยนมากที่นี่และอื่น ๆ ได้อย่างรวดเร็วเว้นแต่ Amazon ได้ทำการตั้งค่า swappiness ของระบบปฏิบัติการด้วยเหตุผลบางอย่าง ความคิดใดที่ว่าทำไมเราถึงต้องทำให้เกิดการใช้ swap อย่างมากใน ElastiCache / Redis หรือวิธีแก้ปัญหาที่เราอาจลอง?

— Josh Kupershmidt
แหล่งที่มา

คำตอบ:

เนื่องจากไม่มีใครมีคำตอบที่นี่คิดว่าฉันจะแบ่งปันสิ่งเดียวที่ได้ผลสำหรับเรา ครั้งแรกความคิดเหล่านี้ใช้งานไม่ได้ :

แคชประเภทอินสแตนซ์ที่ใหญ่กว่า: พบปัญหาเดียวกันกับอินสแตนซ์ขนาดเล็กกว่าแคช r3.2x ขนาดใหญ่ที่เราใช้อยู่ตอนนี้
tweaking maxmemory-policy: ไม่ระเหย -lru หรือ allkeys-lru ดูเหมือนจะสร้างความแตกต่างใด ๆ
กระแทกขึ้น maxmemory-samples
กระแทกขึ้น reserved-memory
บังคับให้ลูกค้าทุกคนตั้งเวลาหมดอายุโดยทั่วไปจะใช้เวลาไม่เกิน 24 ชั่วโมงโดยมีผู้โทรหายากเพียงไม่กี่รายที่อนุญาตให้ใช้งานได้สูงสุด 7 วัน แต่ผู้โทรส่วนใหญ่ใช้เวลาหมดอายุ 1-6 ชั่วโมง

นี่คือสิ่งที่ในที่สุดก็ช่วยได้มาก: การทำงานทุก ๆ สิบสองชั่วโมงซึ่งเรียกใช้การสแกนผ่านคีย์ทั้งหมดเป็น chunks ( COUNT) 10,000 นี่คือ BytesUsedForCache ของอินสแตนซ์เดียวกันนั้นยังคงเป็นอินสแตนซ์ cache.r3.2xlarge ภายใต้การใช้งานที่หนักกว่าเดิมกว่าเดิมด้วยการตั้งค่าแบบเดียวกับก่อนหน้านี้:

ฟันเลื่อยลดลงในการใช้งานหน่วยความจำสอดคล้องกับเวลาของงาน cron ตลอดระยะเวลาสองสัปดาห์นี้การใช้ swap ของเรามียอดถึง ~ 45 MB (วงเงินที่ ~ 5 GB ก่อนที่จะรีสตาร์ทก่อน) และแท็บเหตุการณ์แคชใน ElastiCache จะไม่มีการรีสตาร์ทเหตุการณ์แคชอีกต่อไป

ใช่ดูเหมือนว่า kludge ที่ผู้ใช้ไม่ควรทำเองและ Redis ควรฉลาดพอที่จะจัดการกับการล้างข้อมูลนี้ด้วยตัวเอง เหตุใดจึงใช้งานได้ ดี Redis ไม่ได้ทำมากหรือทำความสะอาดก่อน emptive ของคีย์หมดอายุแทนการพึ่งพาการขับไล่ของคีย์หมดอายุในช่วง GETs หรือถ้า Redis รู้ว่าหน่วยความจำเต็มแล้วมันจะเริ่ม evicting แป้นสำหรับแต่ละชุดใหม่ แต่ทฤษฎีของฉันคือว่า ณ จุดนั้น Redis ถูก hosed แล้ว

— Josh Kupershmidt
แหล่งที่มา

Josh เพียงแค่สงสัยว่าคุณมีความคืบหน้าในการแก้ไขปัญหานี้อีกหรือไม่ เรากำลังประสบสถานการณ์ที่คล้ายกัน คุณยังคงใช้โซลูชันเดิมเหมือนเดิมหรือไม่?

— Andrew C

@AndrewC เรายังคงมีอินสแตนซ์แคชเดียวกันนี้อยู่โดยรอบซึ่งมีพฤติกรรมฟันเลื่อยที่คล้ายกันจาก SCANs และมีการใช้งาน swap น้อยมากในช่วง 3 เดือนที่ผ่านมา - ไม่ดีเท่าที่ผมโพสต์ในคำถาม ทำกิจกรรมห่างจากอินสแตนซ์นี้และSCANงานในคำตอบยังกระตุ้นการล้างข้อมูล AWS จะเสนอคุณสมบัติRedis Clusterซึ่งฉันพนันว่าจะช่วยสำหรับการใช้งานหนัก

— Josh Kupershmidt

ดีใจที่ได้ยิน; เราใช้วิธีการที่คล้ายกันในการลดการโหลดแคชลงในแคชแยกกัน คุณคิดว่าการจัดกลุ่มจะช่วยลดการใช้ swap ได้อย่างไร เพียงแค่ลดภาระโดยรวม

— Andrew C

@JoshKupersh ท่ามกลางฮีโร่ของฉัน

— โมริอาร์ตี

ฉันรู้ว่านี่อาจจะเก่า แต่ฉันวิ่งเข้าไปในนี้ในเอกสารประกอบ aws

https://aws.amazon.com/elasticache/pricing/ พวกเขาระบุว่า r3.2xlarge มีหน่วยความจำ 58.2gb

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html พวกเขาระบุว่าระบบ maxmemory เป็น 62gb (นี่คือเมื่อการเตะนโยบาย maxmemory เข้ามา) และไม่สามารถเปลี่ยนแปลงได้ . ดูเหมือนว่าไม่ว่าอะไรกับ Redis ใน AWS เราจะแลกเปลี่ยน ..

— tlindhardt
แหล่งที่มา

AWS ถูกต้องแล้ว - พวกเขาบอกว่า maxmemory คือ62495129600bytes ซึ่งเท่ากับ 58.2 GiB หน้าการกำหนดราคาที่คุณเชื่อมโยงมีหน่วยความจำในหน่วยของกิ๊บไม่ GB maxmemoryพารามิเตอร์คงจะไม่สามารถแก้ไขได้เพราะมีลูกบิดที่ดีกว่าให้โดย Redis เช่นreserved-memory( แต่ที่หนึ่งไม่ได้ช่วยฉัน ... ) ที่มีความสามารถแก้ไขได้และ AWS ไม่ต้องการให้คุณ misconfiguring โหนดโดยเช่นบอก Redis ไป ใช้หน่วยความจำมากกว่า Elasticache VM จริง ๆ มี

— Josh Kupershmidt