2017-02-01 7 views
7

हम अपने ऐप सर्वर पर एक PHP स्टैक चला रहे हैं जो हमारे कैशिंग परत के लिए एकाधिक अपस्ट्रीम memcached सर्वर (EC2 छोटे उदाहरण) से कनेक्ट करने के लिए स्थानीय रूप से (सॉकेट के माध्यम से) twemproxy का उपयोग करते हैं।Twemproxy Lag एक पुनरारंभ

हर बार मुझे अपने ऐप मॉनिटर से एक चेतावनी मिलती है कि एक पेज लोड समय> 5 सेकंड लेता है। जब ऐसा होता है, तो तत्काल फिक्स प्रत्येक ऐप सर्वर पर twemproxy सेवा को पुनरारंभ करना है, जो एक परेशानी है।

एकमात्र फिक्स मेरे पास अब एक क्रॉन्टाब है जो हर मिनट चलता है और सेवा को पुनरारंभ करता है, लेकिन जैसा कि आप कल्पना कर सकते हैं कि हर मिनट कुछ सेकंड के लिए कुछ भी नहीं लिखा जाता है, जो वांछित, स्थायी समाधान नहीं है।

क्या किसी ने इससे पहले सामना किया है? यदि हां, तो फिक्स क्या था? मैंने एडब्ल्यूएस लोचदार दर्द पर स्विच करने की कोशिश की लेकिन हमारे वर्तमान twemproxy समाधान के समान प्रदर्शन नहीं था।

यहां मेरी twemproxy कॉन्फ़िगरेशन है।

# Note: We are using HA/twemproxy (nutcracker)/memcached proxy 
# So this isn't a default memcache(d) port 
# Each webapp will host the cache proxy, which allows us to connect via socket 
# which should be faster, as no tcp overhead 
# Hash has been manually override from default jenkins to FNV1A_64, which directly aligns with proxy 
port: 0 
<?php echo Hobis_Api_Cache::TYPE_VOLATILE; ?>: 
    options: 
    - <?php echo Memcached::OPT_HASH; ?>: <?php echo Memcached::HASH_FNV1A_64; ?><?php echo PHP_EOL; ?> 
    - <?php echo Memcached::OPT_SERIALIZER; ?>: <?php echo Memcached::SERIALIZER_IGBINARY; ?><?php echo PHP_EOL; ?> 
    servers: 
    - /var/run/nutcracker/nutcracker.sock 

हम 0.4.1 twemproxy और 1.4.25 memcached चल रहे हैं:

default: 
    auto_eject_hosts: true 
    distribution: ketama 
    hash: fnv1a_64 
    listen: /var/run/nutcracker/nutcracker.sock 0666 
    server_failure_limit: 1 
    server_retry_timeout: 600000 # 600sec, 10m 
    timeout: 100 
    servers: 

    - vcache-1:11211:1 
    - vcache-2:11211:1 

और यहाँ php परत के लिए कनेक्शन config है।

धन्यवाद।

+0

यह crontab –

उत्तर

0

मैं स्थानीय होस्ट पर TCP पोर्ट को यूनिक्स सॉकेट से स्विच समाप्त हो गया है और इसे पुनः आरंभ समस्या हल हो गई है लगता है हो सकता है। हालांकि, मैंने टीसीपी से जुड़े ओवरहेड के कारण, स्विच करने में प्रतिक्रिया समय में एक उछाल देखा। उम्मीद में इस सवाल का जवाब नहीं स्वीकार करने सड़क के नीचे किसी सॉकेट के बारे में अधिक आधिकारिक उत्तर पोस्ट करेंगे ...

1

मुझे twemproxy और memcached के बारे में ज्यादा जानकारी नहीं है। लेकिन मैं आपको अधिक जानकारी के लिए एक लिंक देता हूं। हो सकता है कि यह आपके लिए सहायक होगा।

https://github.com/twitter/twemproxy

+0

रेपो मदद नहीं करता है का एक लिंक स्थापित करने की समस्या है, कि मैं कहाँ कोड शुरू में मिल गया है और मेरे पास होने वाले मुद्दे के बारे में कोई उल्लेख नहीं है। –

+0

@ माइकपुर्सेल सॉकेट कनेक्शन समस्या हो सकती है –

+0

@ माइकपुर्सेल टीसीपी सॉकेट बंद होने तक खुला रहता है। वास्तव में डेटा भेजने के बिना टूटा हुआ कनेक्शन (टूटा हुआ, राउटर की मृत्यु के रूप में, आदि के रूप में टूटा हुआ) का पता लगाना बहुत मुश्किल है, इसलिए ज्यादातर एप्लिकेशन यह सुनिश्चित करने के लिए बस इतना ही पिंग/पोंग प्रतिक्रिया करते हैं कि कनेक्शन है अभी भी वास्तव में जिंदा है। –

3

खुला/बासी सॉकेट कनेक्शन की संख्या मुद्दा

+0

हमम कि वे ढेर हो सकते हैं, मैं इसे देख लूंगा। –

+1

तो उसे ओपी की मदद करने की कोशिश नहीं करनी चाहिए थी? उसके पास ऐसा कुछ है जो ओपी को समाधान के लिए निर्देशित कर सकता है, फिर भी आप उसे बंद कर देंगे? मैं कसम खाता हूं कि स्टैक ओवरफ्लो नरसंहार वाले लोगों से भरा है जो सिर्फ अन्य लोगों के अनुभव को बर्बाद करना चाहते हैं ... ओपी इस टिप्पणी को प्राप्त करने में प्रसन्न है, और किरण ने अपनी राय देने के लिए क्या किया, क्योंकि स्टैक उसे टिप्पणी नहीं करेगा ... तो कृपया जोर्न ... छोड़ दो और लोगों को रहने दो। यह एक ऐसी साइट है जहां हम लोगों की मदद करते हैं। किरण की पोस्ट सहायक थी। आपका सबकुछ उपयोगी है लेकिन सहायक है। आपको किरण को ऊपर उठाना। डुनो अगर वह अपनी समस्या का समाधान करेगा लेकिन आपने दूसरों की मदद करने में मदद की - –

संबंधित मुद्दे