AWS इंजीनियरों की रिपोर्ट: Linux 7.0 में PostgreSQL की performance आधी रह गई — इसे ठीक करना आसान नहीं हो सकता

• Amazon/AWS इंजीनियरों ने Linux 7.0 development kernel में PostgreSQL database server की throughput पहले के kernel की तुलना में लगभग आधी रह जाने वाली गंभीर performance regression की पहचान की है
• Graviton4 server पर मापे गए नतीजों में Linux 7.0 ने पिछले kernel की तुलना में लगभग 0.51x throughput ही दी, और इसका कारण user-space spinlock में कहीं अधिक समय खर्च होना पाया गया
• regression का कारण Linux 7.0 में किया गया kernel preemption mode restriction बदलाव है; PREEMPT_NONE को default के रूप में बहाल करने वाला patch submit किया गया है, लेकिन उसके अपनाए जाने की संभावना स्पष्ट नहीं है
• मूल लेखक Peter Zijlstra का कहना है कि kernel बदलने के बजाय PostgreSQL को RSEQ(Restartable Sequences) time-slice extension का उपयोग करने के लिए बदला जाना चाहिए
• Linux 7.0 stable version लगभग 2 हफ्तों में जारी होने वाला है और इसे Ubuntu 26.04 LTS के base kernel के रूप में भी इस्तेमाल किया जाएगा, इसलिए PostgreSQL के अनुकूल होने तक व्यापक performance गिरावट की आशंका है

---

समस्या की खोज और उसका पैमाना

• Amazon/AWS इंजीनियर Salvatore Dipietro ने PostgreSQL की throughput और latency regression की रिपोर्ट की
• Graviton4 server पर माप में Linux 7.0 ने मौजूदा kernel की तुलना में केवल 0.51x throughput दी
  • जांच में पाया गया कि user-space spinlock में काफी अधिक समय खर्च हो रहा है

regression का कारण: preemption mode restriction

• bisecting के नतीजों से यह तय हुआ कि Linux 7.0 में kernel preemption mode को सीमित करने वाला बदलाव ही कारण है
• यह बदलाव आधुनिक CPU architecture के लिए केवल Full और Lazy preemption mode बनाए रखने के उद्देश्य से किया गया था, और Linux 7.0 scheduler update के हिस्से के रूप में शामिल किया गया

submit किए गए patch और kernel maintainer की प्रतिक्रिया

• गंभीर regression को देखते हुए PREEMPT_NONE को default preemption mode के रूप में बहाल करने वाला patch Linux kernel mailing list में submit किया गया
• लेकिन मूल code के लेखक Peter Zijlstra इस patch को स्वीकार करने के पक्ष में नहीं हैं, और उनका कहना है कि समाधान यह है कि PostgreSQL, RSEQ(Restartable Sequences) time-slice extension का उपयोग करे
  • RSEQ time-slice extension भी Linux 7.0 में शामिल फीचर है
  • Zijlstra ने समझाया कि "इससे lock holder preemption exposure को सीमित किया जा सकता है"

प्रभाव का दायरा और रिलीज़ शेड्यूल

• अगर यह रुख बना रहता है, तो PostgreSQL के update होने से पहले Linux 7.0 stable version में कुछ scenarios में PostgreSQL performance काफी गिर सकती है
• Linux 7.0 stable version लगभग 2 हफ्तों में जारी होने वाली है
• Linux 7.0, Ubuntu 26.04 LTS का base kernel होगा, इसलिए अप्रैल के अंत में आने वाली Ubuntu 26.04 LTS पर भी इसका वही असर पड़ सकता है

[unstabler]

सुना है कि kernel developers पिछले करीब 10-20 साल से PostgreSQL developers से कहते आ रहे थे, 'userland में spinlock की सिफारिश नहीं की जाती, इसलिए अच्छा होगा अगर आप इस पर फिर से विचार करें'..

https://x.com/kosaki55tea/status/2040458791536497035

[GN⁺]

Hacker News की राय

• Postgres डेवलपर Andres Freund की LKML फ़ॉलो-अप पोस्ट पढ़ने लायक है

  • अगर performance issue पुनरुत्पादित किया जा सकने वाला regression है, तो इसे ठीक करने के लिए 7.0 में नया जोड़ा गया feature बंद करना अजीब स्थिति है
  • सिर्फ़ एक पोस्ट नहीं, पूरी thread को फ़ॉलो करने पर ज़्यादा जानकारी मिलती है
  • 7.0 में ही होने वाले regression को ठीक करने के लिए 7.0 में नए जोड़े गए low-level feature को मजबूर करना ठीक नहीं है
    यह राय है कि Linux maintainers को PostgreSQL जैसे core apps को प्राथमिक support target मानना चाहिए
    इससे Fedora का वह पुराना मामला याद आता है जिसमें Wine install होने पर update रुक गए थे
  • “hugepages इस्तेमाल करो” वाला समाधान हमेशा सामने आता है, लेकिन ज़्यादातर user इसे नज़रअंदाज़ करते हैं
  • सिर्फ़ ARM64 96-core machine पर performance 0.51x तक गिरा, और AMD64 पर यह दोहराया नहीं गया
    यानी यह समस्या उन सभी users को नहीं होती जो PostgreSQL को नए kernel पर अपग्रेड करते हैं

• user space में spinlock को kernel support के बिना इस्तेमाल करना performance गिरने को न्योता देने जैसा है

  • मुझे भी Postgres में spinlock का इस्तेमाल पसंद नहीं है और इसे धीरे-धीरे हटाया जा रहा है
    लेकिन futex-आधारित lock में memory barrier बढ़ने की वजह से performance regression होता है
    साथ ही Postgres को अब भी ऐसे platform का ध्यान रखना पड़ता है जो 8-byte atomic operation support नहीं करते, इसलिए इसे बदलना आसान नहीं है
    समस्या वाला spinlock हाल ही में हटा दिया गया है, और huge pages इस्तेमाल करने पर bottleneck लगभग गायब हो जाता है
  • user space में spinlock इस्तेमाल करना “खुद के चेहरे पर हथौड़ा मारने” जैसा बताया गया
  • यह भी राय थी कि PostgreSQL ने पुराने kernel compatibility के लिए spinlock बनाए रखे, लेकिन अब इसे छोड़ देने का समय है

• यह दावा भी आया कि “production में कोई भी नया kernel इस्तेमाल नहीं करता”
  लेकिन वास्तव में Ubuntu 26.04 LTS जल्द ही Linux 7.0 आधारित होकर आएगा, इसलिए बहुत से user इसे जल्द इस्तेमाल करेंगे
  अभी समस्या यह है कि sysctl नहीं बल्कि kernel patch की ज़रूरत है

  • फिर भी ऐसे लोगों का होना ज़रूरी है जो नया kernel test करें, तभी ऐसी समस्याएँ जल्दी पकड़ में आती हैं
  • अगर PostgreSQL प्रभावित है, तो दूसरे applications पर भी असर पड़ सकता है
  • Docker environment में host kernel साझा होता है, इसलिए choice नहीं होती, यह बात भी कही गई
  • संदर्भ के लिए, PREEMPT_NONE option ज़्यादातर platforms से हटा दिया गया है

• PREEMPT_LAZY की पृष्ठभूमि LWN लेख में देखी जा सकती है

• एक हल्की-फुल्की टिप्पणी थी, “क्या आपने देखा कि Jia Tan ने हाल में कोई kernel patch भेजा है?”
  इस पर जवाब आया, “उसकी भी ज़रूरत नहीं, पहले से ही काफ़ी vulnerabilities भरी पड़ी हैं”

• किसी ने पूछा कि PostgreSQL 18 की asynchronous I/O और parallel query optimization क्या इस performance गिरावट की भरपाई कर सकती है
  इससे जुड़ी जानकारी PostgreSQL 18 release notes में देखी जा सकती है

• यह सवाल भी उठा कि PREEMPT_LAZY जैसे dynamic preemption mode की ज़रूरत ही क्यों है
  मतलब आम users को इससे क्या फ़ायदा मिलता है, यह स्पष्ट नहीं है

  • इसके जवाब में कहा गया कि इसका उद्देश्य latency बढ़ाए बिना throughput बढ़ाना है
    यानी kernel को और स्पष्ट जानकारी मिलती है, जिससे वह scheduling decision बेहतर कर सके

• एक टिप्पणी में कहा गया कि FreeBSD 14 और 15.0 के बीच 10% performance drop मापा गया था, इसलिए यह मामला देखकर थोड़ी तसल्ली मिली

  • इसके बाद प्रतिक्रिया आई, “फिर क्या कम से कम उतने feature भी जुड़े?”

• Phoronix पर यह आलोचना भी हुई कि उसने काफ़ी verification के बिना article छाप दिया
  फ़ॉलो-अप mail में निष्कर्ष निकला कि benchmark ही ग़लत था और वास्तव में यह कोई बड़ी समस्या नहीं थी

  • हालाँकि regression सिर्फ़ तब होता है जब huge pages इस्तेमाल नहीं किए जाते
    PostgreSQL के लिए शायद यह बड़ी समस्या न हो, लेकिन उन दूसरे apps पर असर पड़ सकता है जो huge pages इस्तेमाल नहीं कर सकते
    इसलिए इसे पूरी तरह नज़रअंदाज़ करने वाली बात नहीं मानी गई

• एक पुराना LKML thread link भी साझा किया गया था