ทำความเข้าใจกับข้อผิดพลาดนี้: apr_socket_recv: รีเซ็ตการเชื่อมต่อโดยเพียร์ (104)


14

ดังนั้นถ้าฉันทำการเปรียบเทียบกับ apache benchmark (ab) และฉันใช้การร้องขอจำนวนมาก จากนั้นบางครั้งในระหว่างการทดสอบฉันได้รับข้อผิดพลาดนี้

ฉันไม่รู้ด้วยซ้ำว่ามันหมายถึงอะไร ดังนั้นฉันจะแก้ไขได้อย่างไร หรือเป็นเพียงบางสิ่งที่จะเกิดขึ้นหากเซิร์ฟเวอร์ได้รับความนิยมมากเกินไป ปัญหาคือถ้าฉันวิ่ง 10,000 ครั้งมันจะทำงานได้อย่างสมบูรณ์แบบ หากฉันเรียกใช้อีกครั้งจะได้รับถึง 4,000 และได้รับข้อผิดพลาด:

apr_socket_recv: Connection reset by peer (104)

เล็ก ๆ น้อย ๆ เกี่ยวกับการตั้งค่าของฉัน: ฉันมี nginx รับคำขอคงที่และการประมวลผลแบบไดนามิกเพื่อ Apache ไฟล์ที่เป็นปัญหาถูกนำเสนอจากแคชโดย nginx ดังนั้นฉันคิดว่ามันน่าจะเกี่ยวข้องกับวิธีที่ nginx จัดการกับคำร้องขอ?

ไอเดีย?

คำตอบ:


7

ข้อผิดพลาดหมายความว่าปลายอีกด้าน (เว็บเซิร์ฟเวอร์) ตัดการเชื่อมต่อทันทีในช่วงกลางของเซสชัน ดูที่ apache หรือ nginx error log เพื่อดูว่ามีสิ่งที่น่าสงสัยหรือไม่


4

หมายความว่าเซิร์ฟเวอร์ถูกโหลดอย่างหนักพร้อมกับคำขอนั่นคือเธรดทั้งหมดไม่ว่างให้บริการตามคำขอ โซลูชัน: เพิ่มจำนวนแอ็ตทริบิวต์ maxThread สำหรับตัวเชื่อมต่อในไฟล์ server.xml หรือเพิ่มค่าแอตทริบิวต์ acceptCount

acceptcount: ความยาวคิวสูงสุดสำหรับการร้องขอการเชื่อมต่อขาเข้าเมื่อมีการใช้เธรดการประมวลผลการร้องขอที่เป็นไปได้ทั้งหมด คำร้องขอใด ๆ ที่ได้รับเมื่อคิวเต็มจะถูกปฏิเสธ


0

ฉันมีปัญหาเดียวกันและรุ่นเซิร์ฟเวอร์ของฉันคือ:

Server Version: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.6.5 mod_perl/2.0.9dev Perl/v5.16.3

ฉันลบโมดูลที่ไม่จำเป็นและปัญหาหายไป:

Server Version: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips

ดังนั้นหนึ่งในmod_fcgid , mod_phpหรือmod_perlทำให้เกิดปัญหา คุณสามารถลองปิดการใช้งานหากคุณไม่ได้ใช้

(หมายเหตุด้านข้าง; หากคุณใช้ opcache ให้ปิดการใช้งาน fast_shutdown ด้วยเช่นกันซึ่งเป็นสาเหตุของปัญหาด้วยเช่นกัน: opcache.fast_shutdown = 0)


0

นอกจากคำตอบที่นี่ฉันได้อ่านคำถามอื่น ๆ มากมาย:

ไม่มีใครช่วย

ฉันคิดเกี่ยวกับการเปลี่ยนไปwrkหลังจากที่ได้เห็นการต่อสู้ที่คล้ายกัน

การค้นหาปัญหา

ปัญหาน่าจะเกี่ยวข้องกับจำนวนของพอร์ต ephermal ฉันพยายามตั้งจาก 50,000 ถึง 25000 เพราะนี่คือช่วงพอร์ต ยังไม่มีโชค จากนั้นฉันก็ประทับใจที่เกี่ยวข้องกับ TIME_WAIT และโพสต์บล็อกนี้ ฉันคิดว่าฉันสามารถยืนยันได้ว่า:

$ netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n

    1 CLOSE_WAIT
    1 established)
    1 Foreign
    4 LISTEN
    8 SYN_SENT
   62 SYN_RECV
  351 ESTABLISHED
13916 TIME_WAIT

สิ่งที่ฉันพยายาม

ฉันไม่ได้แก้ไขจนถึงตอนนี้: /

ตามที่sudo sysctl -a | grep net.ipv4.tcpฉันมี:

net.ipv4.tcp_tw_reuse = 0    # No luck setting only that to 1
net.ipv4.tcp_max_tw_buckets = 32768
net.ipv4.tcp_fin_timeout = 60  # Setting it to 5 didn't help either

-1

ปัญหานี้เกิดจากระบบ ถ้าให้คำร้องขอพร้อมกันสูงกับระบบ เคอร์เนลระบบปฏิบัติการจะเรียกใช้การป้องกันน้ำท่วม SYN ดังนั้นระบบจะรีเซ็ตลิงค์ คุณสามารถแก้ไขการตั้งค่าระบบปฏิบัติการในไฟล์

#vi /etc/sysctl.conf
net.ipv4.tcp_syncookies = 0 # set value is 0
#sysctl -p # read config from the config file.

คุณสามารถลอง

โดยปกติแล้วแอททริบิวต์net.ipv4.tcp_syncookiesนี้ใช้เพื่อป้องกันระบบปฏิบัติการเพื่อหลีกเลี่ยงการโจมตีที่ร้องขอจำนวนมาก แต่ถ้าคุณต้องการใช้ระบบปฏิบัติการนี้เพื่อทำการทดสอบโหลดหรือทดสอบประสิทธิภาพคุณควรปิดคุณสมบัตินี้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.