AWS EC2 + (P)Redis cache

Ahoj, mám tu takový divný problém, který nemůžu rozlousknout. Pomalu připravuji k migraci jednu větší službu z ČR na AWS, kde mi beží EC2 + RDS (mysql) + Elasticache jako Redis. Právě Redis drží cca 50 klíčů se slovníkama, nic velkýho, pár záznamů. Jediné operace, které se využívají (pokud nepočítám jednou za čas refill) je defakto EXIST, HLEN a HMGET. Děje se to, že každá z 15 takových operací, kde figuruje defakto jen EXIST a HMGET proběhne v čase 0.00X sekundy a vždy cca 16tá trvá řádově dvacetkrát déle - 0.2 sekundy. Potom se to opakuje. Normálně si toho sotva člověk všimne, ale nevím co to bude dělat s větší zátěží (zkusím později přes AB). K Redis serveru přistupuje Predis. Je jedno jetli Redis běží na T2 micro/small nebo M3 instancích, opakuje se to vždy stejně. https://bestpornlist.pro Vše jsem otagoval a začal měřit do logu a viník je funkce EXIST, která prostě jednou za 10-15 použití hodí takový menší "lag". Vesměs jen kontroluje existenci 1 z cca 15 klíčů a případně obnoví cache (tím to ale není, to si měřím taky). Redis nemá nastavené zálohy, replikace, běží jako 1 node, má jen pár klíčů s nastavenou expirací. Nemáte někdo tucha?

Pro redis u AWS musíš volit HVM instance (např. m3.medium), redis pro nová spojení používá fork(2) syscall a ten u těch slabších instancí v AWS způsobuje lagy. Při větší zátěži to bude patrné pouze pokud budeš znovu a znovu vytvářet nová spojení. Částečným řešením může být si držet jedno spojení na redis a zůstat v jednom vláknu, které je už forknuté, případně využít nějaký LB, který ty spojení drží, pak to je rychlé.Ověř si, že jsi deaktivoval transparent_hugepage, její aktivace (což je výchozí) způsobuje také lagy v případě redisu. Zapni si měření na straně redisu (latency monitor od redisu cca 2.8.14), abys vyloučil problémy se sítí, opět v AWS nic mimořádného a děje se to často, vyhrazená vlan to řeší.Exists je viníkem pravděpodobně proto, že jí v chainu voláš jako první, hm?Na přesnější odpověď bych potřeboval více informací. Tip do budoucna, pozor na zálohy, umisťuj je vždy do jiné AZ, není vyjímka pádu celé lokality, rovnou vše navrhují distrubovaně, ušetříš si spoustu problémů a klientovi to prezentuji jako jedinou cestu.