เพราะเหตุใดเวลาตอบสนองจึงเพิ่มขึ้นเมื่อคำขอลดความถี่

การแก้ไข : เวลาตอบสนอง ( %D) คือμไม่ใช่ ms! 1

สิ่งนี้ไม่เปลี่ยนแปลงอะไรเกี่ยวกับความแปลกของรูปแบบนี้ แต่หมายความว่ามันจะทำลายล้างได้น้อยลง

เหตุใดเวลาตอบกลับจึงมีความสัมพันธ์ตรงกันข้ามกับการขอความถี่

เซิร์ฟเวอร์ไม่ควรตอบสนองเร็วขึ้นเมื่อคำขอจัดการไม่ว่างน้อยลงหรือไม่

ข้อเสนอแนะใด ๆ ที่จะทำให้ Apache "ใช้ประโยชน์จาก" โหลดได้น้อยลง?

รูปแบบนี้เป็นระยะ ซึ่งหมายความว่าจะปรากฏขึ้นหากการแสดงผลลดลงต่ำกว่าประมาณ 200 คำขอต่อนาที - ซึ่งเกิดขึ้น (เนื่องจากกิจกรรมผู้ใช้ทั่วไป) ตั้งแต่ดึกถึงเช้า

คำขอนั้นง่ายมาก POSTs ที่ส่ง JSON ที่มีความยาวน้อยกว่า 1,000 ตัวอักษร - JSON นี้จะถูกเก็บไว้ (ต่อท้ายไฟล์ข้อความ) - นั่นคือมัน การตอบกลับเป็นเพียง "-"

ข้อมูลที่แสดงในกราฟถูกบันทึกด้วย Apache เอง:

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

นี่เป็นพฤติกรรมทั่วไปในศูนย์ข้อมูล เวลาที่เวลาตอบสนองของคุณช้านั้นสอดคล้องกับสิ่งที่เรียกว่า Batch Window นี่เป็นช่วงเวลาหนึ่งที่กิจกรรมของผู้ใช้คาดว่าจะอยู่ในระดับต่ำและสามารถประมวลผลแบตช์ได้ สำรองข้อมูลจะทำในช่วงเวลานี้ กิจกรรมเหล่านี้สามารถกดดันทรัพยากรของเซิร์ฟเวอร์และเครือข่ายที่ก่อให้เกิดปัญหาประสิทธิภาพเช่นที่คุณเห็น

มีทรัพยากรบางอย่างที่อาจทำให้เกิดปัญหา:

• โหลด CPU สูง สิ่งนี้อาจทำให้ apache รอชิ้นเวลาประมวลผลการร้องขอ
• การใช้งานหน่วยความจำสูง สิ่งนี้สามารถล้างข้อมูลบัฟเฟอร์ที่เปิดใช้งาน apache เพื่อให้บริการทรัพยากรโดยไม่ต้องอ่านจากดิสก์ นอกจากนี้ยังสามารถทำให้เกิดการสลับหน้า / สลับของคนงาน apache
• กิจกรรมดิสก์สูง สิ่งนี้สามารถทำให้กิจกรรมดิสก์ I / O ถูกจัดคิวด้วยความล่าช้าที่สอดคล้องกันในการให้บริการเนื้อหา
• กิจกรรมเครือข่ายสูง สิ่งนี้อาจทำให้แพ็คเก็ตถูกจัดคิวเพื่อการส่งเพิ่มความพยายามและลดการบริการ

ฉันใช้sarเพื่อตรวจสอบออกเช่นนี้ atsarสามารถใช้รวบรวมsarข้อมูลเป็นไฟล์ข้อมูลรายวัน สิ่งเหล่านี้สามารถตรวจสอบได้เพื่อดูว่าพฤติกรรมของระบบเป็นอย่างไรในช่วงเวลากลางวันเมื่อประสิทธิภาพเป็นปกติและเขียนทับเมื่อประสิทธิภาพเป็นตัวแปร

หากคุณกำลังตรวจสอบระบบด้วยmuninหรือระบบอื่น ๆ ที่รวบรวมและกราฟการใช้ทรัพยากรคุณอาจพบตัวบ่งชี้บางอย่างที่นั่น ฉันยังพบsarแม่นยำมากขึ้น

มีเครื่องมือที่ชอบniceและioniceสามารถนำไปใช้กับกระบวนการแบทช์เพื่อลดผลกระทบได้ มันมีประสิทธิภาพสำหรับปัญหา CPU หรือ I / O เท่านั้น พวกเขาไม่น่าจะแก้ไขปัญหาเกี่ยวกับกิจกรรมของหน่วยความจำหรือเครือข่าย

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

คุณอาจสามารถ จำกัด จำนวนของกระบวนการแบบแบ็ตช์ที่ทำงานแบบขนานทั้งนี้ขึ้นอยู่กับวิธีการประมวลผลแบทช์ นี่อาจช่วยปรับปรุงประสิทธิภาพของกระบวนการแบทช์เนื่องจากพวกเขามีแนวโน้มที่จะเกิดความขัดแย้งในทรัพยากรเดียวกัน

ความสัมพันธ์นี้อาจเกิดขึ้นในอีกทางหนึ่งหากผู้ส่งคำขอรอคำขอก่อนหน้าให้เสร็จสมบูรณ์ก่อนที่จะส่งคำขอใหม่ ในกรณีนั้นปริมาณการใช้งานลดลงตามเวลาที่ร้องขอเพิ่มขึ้น (ไม่ว่าด้วยเหตุผลใดก็ตาม) เนื่องจากการเข้าคิวฝั่งไคลเอ็นต์

หรืออาจเป็นสิ่งประดิษฐ์ของการวัดของคุณ - หากกราฟด้านบนแสดงคำขอที่เสร็จสมบูรณ์ซึ่งตรงข้ามกับคำขอที่มาถึงอัตราจะลดลงเมื่อเวลาในการประมวลผลคำขอเพิ่มขึ้น

แม้ว่าคำตอบของ @ BillThor อาจจะถูกต้อง แต่ดูเหมือนว่าไม่น่าจะเป็นไปได้ว่าช่วงเวลาของการโหลดต่ำนั้นเกิดขึ้นโดยกระบวนการสำรองข้อมูลทั้งหมด

คำอธิบายทางเลือกคือการแคช หากสคริปต์ / ฐานข้อมูล / สิ่งใด ๆ ที่ไม่ได้ใช้งานเมื่อเร็ว ๆ นี้ข้อมูลแคชที่เกี่ยวข้องอาจถูกนำไปทิ้งเพื่อเพิ่มหน่วยความจำสำหรับส่วนที่เหลือของระบบปฏิบัติการ นี่อาจเป็นดัชนีในฐานข้อมูลหรือบัฟเฟอร์ O / S ที่สัมพันธ์กับไฟล์หรือสิ่งอื่นที่คล้ายคลึงกัน แบบสอบถามจะต้องสร้างข้อมูลนี้ใหม่หากไม่ได้ใช้เวลานานนับตั้งแต่มีการสืบค้นครั้งล่าสุด ในช่วงเวลาที่ยุ่งสิ่งนี้จะไม่เกิดขึ้นเนื่องจากการสืบค้นล่าสุดจะเกิดขึ้นบ่อยครั้ง นี่จะอธิบายว่าทำไมคุณจึงเห็นเวลาตอบสนองที่ต่ำและเวลาตอบสนองที่สูงในช่วงที่ยุ่ง

สำหรับฉันสิ่งที่คุณเห็นมีลักษณะเหมือนว่ามันอาจเป็นปัญหาทางสถิติ อาจไม่เป็นเช่นนั้นคำตอบของ @ BillThor อาจจะถูกต้อง แต่ฉันจะโพสต์สิ่งนี้เพื่อความสมบูรณ์

กราฟเวลาตอบสนองนั้นเป็นเปอร์เซ็นต์ไทล์ กลุ่มตัวอย่างที่มีคำขอ 800-1000 ตัวอย่างเป็นจำนวนตัวอย่างที่ดีสำหรับเรื่องนี้กลุ่มที่มีคำขอ 50-100 รายการอาจไม่มากนัก

หากคุณสมมติว่าจำนวนคำขอที่ช้านั้นไม่ใช่ฟังก์ชันเชิงเส้นของปริมาณคำขอเช่นว่าลำดับการเพิ่มขนาดในคำขอไม่ได้ส่งผลให้ลำดับที่เพิ่มขึ้นของคำขอช้านั้นจะส่งผลให้ปริมาณคำขอสูงขึ้น เวลาขอเฉลี่ยที่ต่ำกว่า

มีคำโกหกคำโกหกคำโตและสถิติ

สมมติฐานของฉัน: คุณมีคำขอที่แตกต่างกันสามประเภท:

1. สตรีมตัวแปรปกติที่มีการร้องขอส่วนใหญ่และสิ่งเหล่านี้จะเสร็จสมบูรณ์ภายใน 200-300 μs
2. สตรีมขนาดเล็กในอัตราคงที่ประมาณ 20 คำขอต่อนาที (แม้ในเวลากลางคืน) แต่ละอันใช้เวลาประมาณ 2.500 ไมโครวินาทีในการทำให้สมบูรณ์
3. สตรีมจิ๋วที่อัตราคงที่ประมาณ 10 คำขอต่อนาที (แม้ในเวลากลางคืน) แต่ละอันมีค่ามากกว่า 4.000 μs

ในเวลากลางคืน 50 คำขอต่อนาทีสอดคล้องกัน 20 + 20 + 10 ดังนั้นผลลัพธ์ของเปอร์เซ็นไทล์ 50% จึงขึ้นอยู่กับผลลัพธ์ของสตรีม 2 เป็นอย่างมากและเปอร์เซ็นไทล์ 95% นั้นขึ้นอยู่กับสตรีม 3 ดังนั้นจึงไม่สามารถแสดงบนกราฟได้

ในระหว่างวันลำธาร 2 + 3 นั้นถูกซ่อนไว้อย่างดีเหนือเปอร์เซ็นไทล์ 95%

ยิ่งฉันมองมันมากเท่าไหร่ฉันก็ยิ่งคิดว่ามีปัญหากับการรวบรวมข้อมูล

ก่อนอื่นมีบางอย่างแปลก ๆ เกิดขึ้นกับ TPS ของคุณ ในขณะที่รูปแบบโดยรวมดูปกติมีการแบ่งที่คมชัดมากเกิดขึ้นเวลาประมาณ 21.00 น. จากนั้นอีกครั้งเวลาประมาณ 7 โมงเช้า แผนภูมิปกติจะราบรื่นกว่ามากในระหว่างการเปลี่ยนเป็นชั่วโมงที่มีการใช้งานน้อย

นั่นแสดงให้เห็นว่ามีการเปลี่ยนแปลงในโปรไฟล์และคุณอาจมีลูกค้า 2 ประเภทที่แตกต่างกัน:

1. หนึ่งที่ทำงานระหว่าง 7am (ish) และ 21:00 (ish) ที่ปริมาณสูงและ
2. อีกอันที่อาจทำงานได้ตลอดเวลาในระดับเสียงที่ต่ำกว่า

คำใบ้ที่สองประมาณเวลา 18:00 น. ส่วนใหญ่เวลาก่อนและหลังเรามีสูงรายละเอียดปริมาณ - TPS สูงและ latency ต่ำ แต่เวลาประมาณ 18:00 น. จะมีการลดลงอย่างกระทันหันจาก 800-1,000 รอบต่อนาทีเป็นน้อยกว่า 400 รอบต่อนาที อะไรที่อาจทำให้เกิดสิ่งนั้น

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

ดังนั้นการลดระดับลงในเปอร์เซ็นไทล์อันดับที่ 5 จึงบอกกับฉันว่ามีการหยุดกระทันหันในซีรีย์และเวลาบริการลดลงจริง ๆ แล้วทั้งความแปรปรวนและเวลาตอบสนองเฉลี่ยเพิ่มขึ้นอย่างมาก

ขั้นตอนถัดไป

ในขั้นตอนนี้ฉันจะดำดิ่งลงสู่ท่อนซุงเพื่อค้นหาว่าอะไรคือความแตกต่างของตัวอย่างปริมาณต่ำ 18:00 เมื่อเทียบกับตัวอย่างที่มีปริมาณสูงก่อนและหลัง

ฉันจะมองหา:

• ความแตกต่างในที่ตั้งทางภูมิศาสตร์ (ในกรณีเวลาแฝงส่งผลกระทบต่อ $ request_time)
• ความแตกต่างใน URL (ไม่ควรมี)
• ความแตกต่างในวิธี HTTP (POST / GET) (ไม่ควรมี)
• คำขอซ้ำจาก IP เดียวกัน
• และความแตกต่างอื่น ๆ ...

BTW เหตุการณ์ "18:00" เป็นหลักฐานเพียงพอสำหรับฉันที่ว่าไม่มีอะไรเกี่ยวข้องกับความหนาแน่นของศูนย์ข้อมูล / กิจกรรม เพื่อที่จะเป็นจริงความแออัดจะต้องทำให้ลดลงใน TPS ซึ่งเป็นไปได้ที่ 18:00 แต่ไม่น่าเป็นไปได้อย่างยิ่งที่จะทำให้เกิดการยั่งยืนและลดลงอย่างราบรื่นโค้งใน TPS เป็นเวลา 10 ชั่วโมงระหว่าง 21: 00-07: 00