אָדיססיי ראָאַדמאַפּ: וואָס אַנדערש טאָן מיר וועלן פון אַ פֿאַרבינדונג פּולער. אַנדריי באָראָדין (2019)

אין זיין באַריכט, Andrey Borodin וועט זאָגן איר ווי זיי האָבן גענומען אין חשבון די דערפאַרונג פון סקיילינג PgBouncer ווען דיזיינינג די פֿאַרבינדונג פּולער אָדיססיי, ווי זיי ראָולד עס אויס אין פּראָדוקציע. אין אַדישאַן, מיר וועלן דיסקוטירן וואָס פאַנגקשאַנז פון די פּולער מיר וואָלט ווי צו זען אין נייַע ווערסיעס: עס איז וויכטיק פֿאַר אונדז ניט בלויז צו טרעפן אונדזער באדערפענישן, אָבער צו אַנטוויקלען די באַניצער קהל אָדיססיי.

וידאו:

א גוטן יעדער! מיין נאָמען איז ענדרו.

אין יאַנדעקס, איך אַנטוויקלען אָפֿן מקור דאַטאַבייסיז. און הייַנט מיר האָבן אַ טעמע וועגן פֿאַרבינדונג פּאָאָלער קאַנעקשאַנז.

אויב איר וויסן ווי צו רופן פֿאַרבינדונג פּאָאָלער אין רוסיש, זאָגן מיר. איך טאַקע ווילן צו געפֿינען אַ גוט טעכניש טערמין וואָס זאָל זיין געגרינדעט אין די טעכניש ליטעראַטור.

די טעמע איז גאַנץ קאָמפּליצירט, ווייַל אין פילע דאַטאַבייסיז די פֿאַרבינדונג פּאָאָלער איז געבויט אין און איר טאָן ניט אפילו דאַרפֿן צו וויסן וועגן אים. פון קורס, עס זענען עטלעכע סעטטינגס אומעטום, אָבער אין Postgres עס אַרבעט נישט אַזוי. און אין פּאַראַלעל (ביי HighLoad ++ 2019) עס איז אַ באַריכט פון Nikolai Samokhvalov וועגן באַשטעטיקן פֿראגן אין Postgres. און ווי איך פֿאַרשטיין עס, מענטשן געקומען אַהער וואָס האָבן שוין קאַנפיגיערד זייער פֿראגן בישליימעס, און דאָס זענען מענטשן וואָס זענען פייסט מיט מער זעלטן סיסטעם פּראָבלעמס שייַכות צו די נעץ און מיטל יוטאַלאַזיישאַן. און אין עטלעכע ערטער עס קען זיין גאַנץ שווער אין דעם זינען אַז די פראבלעמען זענען נישט קלאָר ווי דער טאָג.

Yandex האט Postgres. פילע יאַנדעקס באַדינונגס לעבן אין Yandex.Cloud. און מיר האָבן עטלעכע פּעטאַביטעס פון דאַטן וואָס דזשענערייט בייַ מינדסטער אַ מיליאָן ריקוועס פּער סעקונדע אין Postgres.

און מיר צושטעלן אַ פערלי נאָרמאַל קנויל פֿאַר אַלע סערוויסעס - דאָס איז די הויפּט ערשטיק נאָדע פון ​​די נאָדע, די געוויינטלעך צוויי רעפּלאַקאַז (סינטשראָנאָוס און ייסינגקראַנאַס), באַקאַפּ, סקיילינג פון לייענען ריקוועס אויף די רעפּליקע.

יעדער קנויל נאָדע איז Postgres, אויף וואָס, אין אַדישאַן צו Postgres און מאָניטאָרינג סיסטעמען, אַ פֿאַרבינדונג פּולער איז אויך אינסטאַלירן. קאַנעקשאַן פּולער איז געניצט פֿאַר פענסינג און פֿאַר זייַן הויפּט ציל.

וואָס איז דער הויפּט ציל פון קשר פּולער?

Postgres אַדאַפּץ אַ פּראָצעס מאָדעל ווען ארבעטן מיט אַ דאַטאַבייס. דעם מיטל אַז איין קשר איז איין פּראָצעס, איין פּאָסטגרעס באַקענד. און אין דעם באַקענד עס זענען אַ פּלאַץ פון פאַרשידענע קאַטשעס, וואָס זענען גאַנץ טייַער צו מאַכן אַנדערש פֿאַר פאַרשידענע קאַנעקשאַנז.

אַדדיטיאָנאַללי, Postgres קאָד האט אַ מענגע גערופן procArray. עס כּולל יקערדיק דאַטן וועגן נעץ קאַנעקשאַנז. און כּמעט אַלע פּראָקאַררייַ פּראַסעסינג אַלגערידאַמז האָבן לינעאַר קאַמפּלעקסיטי; זיי לויפן איבער די גאנצע מענגע פון ​​נעץ קאַנעקשאַנז. עס איז אַ שיין שנעל ציקל, אָבער מיט מער ינקאַמינג נעץ קאַנעקשאַנז, די טינגז ווערן אַ ביסל מער טייַער. און ווען די טינגז ווערן אַ ביסל מער טייַער, איר קענען סוף אַרויף פּייינג אַ זייער הויך פּרייַז פֿאַר אַ פּלאַץ פון נעץ קאַנעקשאַנז.

עס זענען 3 מעגלעך אַפּראָוטשיז:

• אויף די אַפּלאַקיישאַן זייַט.
• אויף די דאַטאַבייס זייַט.
• און צווישן, דאָס איז, אַלע מינים פון קאַמבאַניישאַנז.

צום באַדויערן, די געבויט-אין פּולער איז דערווייַל אונטער אַנטוויקלונג. אונדזער פרענדז ביי PostgreSQL Professional טאָן דאָס מערסטנס. ווען עס וועט דערשייַנען איז שווער צו פאָרויסזאָגן. און אין פאַקט, מיר האָבן צוויי סאַלושאַנז פֿאַר דער אַרכיטעקט צו קלייַבן פון. דאס זענען אַפּלאַקיישאַן-זייַט בעקן און פּראַקסי בעקן.

אַפּפּליקאַטיאָן-זייַט בעקן איז די יזיאַסט וועג. און כּמעט אַלע קליענט דריווערס צושטעלן איר מיט אַ וועג: פאָרשטעלן מיליאַנז פון דיין קאַנעקשאַנז אין קאָד ווי עטלעכע טוץ קאַנעקשאַנז צו די דאַטאַבייס.

דער פּראָבלעם וואָס ערייזאַז איז אַז אין אַ זיכער פונט איר ווילן צו וואָג די באַקענד, איר ווילן צו צעוויקלען עס צו פילע ווירטואַל מאשינען.

דערנאָך איר פאַרשטיין אַז איר האָבן עטלעכע מער אַוויילאַבילאַטי זאָנעס, עטלעכע דאַטן סענטערס. און דער צוגאַנג צו דער קליענט זייַט פּולינג פירט צו גרעסערע נומערן. גרויס אָנעס זענען וועגן 10 קאַנעקשאַנז. דאָס איז דער ברעג וואָס קען אַרבעטן נאָרמאַלי.

אויב מיר רעדן וועגן פּראַקסי פּאָאָלערס, עס זענען צוויי פּאָאָלערס וואָס קענען טאָן אַ פּלאַץ פון טינגז. זיי זענען נישט בלויז פּאָאָלערס. זיי זענען פּאָאָלערס + מער קיל פאַנגקשאַנאַליטי. דאס Pgpool и קרונטשי-פּראָקסי.

אָבער, ליידער, ניט אַלעמען דאַרף דעם נאָך פאַנגקשאַנאַליטי. און דאָס פירט צו דעם פאַקט אַז פּאָאָלערס שטיצן בלויז סעסיע פּאָאָלינג, ד"ה איין ינקאַמינג קליענט, איין אַוטגאָוינג קליענט צו די דאַטאַבייס.

דאָס איז נישט זייער פּאַסיק פֿאַר אונדזער צוועקן, אַזוי מיר נוצן PgBouncer, וואָס ימפּלאַמאַנץ טראַנסאַקטיאָן פּאָאָלינג, ד"ה סערווער קאַנעקשאַנז זענען מאַטשט צו קליענט קאַנעקשאַנז בלויז פֿאַר די געדויער פון די טראַנסאַקטיאָן.

און אין אונדזער ווערקלאָוד, דאָס איז אמת. אבער עס זענען עטלעכע פראבלעמען.

די פראבלעמען אָנהייבן ווען איר ווילן צו דיאַגנאָזירן אַ סעסיע, ווייַל אַלע דיין ינקאַמינג קאַנעקשאַנז זענען היגע. אַלעמען געקומען מיט אַ לופּבאַקק און עפעס עס ווערט שווער צו שפּור די סעסיע.

דאָך איר קענען נוצן application_name_add_host. דאָס איז אַ וועג אויף די באַונסער זייַט צו לייגן אַן IP אַדרעס צו application_name. אָבער אַפּפּליקאַטיאָן_נאַמע איז באַשטימט דורך אַן נאָך קשר.

אויף דעם גראַפיק, ווו די געל שורה איז פאַקטיש ריקוועס, און ווו די בלוי שורה איז ריקוועס וואָס פליען אין די דאַטאַבייס. און דער חילוק איז פּונקט די ינסטאַלירונג פון אַפּלאַקיישאַן_נאַמע, וואָס איז דארף בלויז פֿאַר טרייסינג, אָבער עס איז נישט פריי.

אין אַדישאַן, אין באַונסער איר קענען נישט באַגרענעצן איין בעקן, ד"ה די נומער פון דאַטאַבייס קאַנעקשאַנז פּער ספּעציפיש באַניצער, פּער ספּעציפיש דאַטאַבייס.

וואָס טוט דאָס פירן צו? איר האָט אַ לאָודיד דינסט געשריבן אין C ++ און ערגעץ נירביי אַ קליין דינסט אויף אַ נאָדע וואָס טוט נישט טאָן עפּעס שרעקלעך מיט די דאַטאַבייס, אָבער זיין שאָפער איז משוגע. עס אָפּענס 20 קאַנעקשאַנז און אַלץ אַנדערש וועט וואַרטן. אפילו דיין קאָד איז נאָרמאַל.

מיר, פון קורס, געשריבן אַ קליין לאַטע פֿאַר באַונסער וואָס צוגעגעבן דעם באַשטעטיקן, ד"ה לימיטעד קלייאַנץ צו די בעקן.

עס וואָלט זיין מעגלעך צו טאָן דאָס אויף די Postgres זייַט, ד"ה באַגרענעצן די ראָלעס אין די דאַטאַבייס דורך די נומער פון קאַנעקשאַנז.

אָבער דעמאָלט איר פאַרלירן די פיייקייט צו פֿאַרשטיין וואָס איר האָבן קיין קאַנעקשאַנז צו די סערווער. PgBouncer טוט נישט וואַרפן אַ קשר טעות, עס שטענדיק קערט די זעלבע אינפֿאָרמאַציע. און איר קענען נישט פֿאַרשטיין: אפֿשר דיין פּאַראָל איז פארענדערט, אפֿשר די דאַטאַבייס נאָר פאַרפאַלן, אפֿשר עפּעס איז פאַלש. אבער עס איז קיין דיאַגנאָסיס. אויב אַ סעסיע קענען ניט זיין געגרינדעט, איר וועט נישט וויסן וואָס עס קען נישט זיין געגרינדעט.

אין אַ זיכער פונט, איר קוק אין די אַפּלאַקיישאַן גראַפס און זען אַז די אַפּלאַקיישאַן איז נישט ארבעטן.

קוק אין די שפּיץ און זען אַז באָונסער איז איין-פאָדעם. דאָס איז אַ טורנינג פונט אין דעם לעבן פון די דינסט. איר פאַרשטיין אַז איר האָט פּריפּערינג צו וואָג די דאַטאַבייס אין אַ יאָר און אַ האַלב, און איר דאַרפֿן צו וואָג די פּאָאָלער.

מיר האָבן קומען צו די מסקנא אַז מיר דאַרפֿן מער PgBouncers.

https://lwn.net/Articles/542629/

באָונסער איז געווען פּאַטשט אַ ביסל.

און זיי געמאכט עס אַזוי אַז עטלעכע באַונסערס קען זיין אויפשטיין דורך ריוזינג די TCP פּאָרט. און די אָפּערייטינג סיסטעם אויטאָמאַטיש טראַנספערס ינקאַמינג טקפּ קאַנעקשאַנז צווישן זיי מיט ראָונד-ראָבין.

דאָס איז טראַנספּעראַנט פֿאַר קלייאַנץ, טייַטש עס קוקט ווי איר האָבן איין באַונסער, אָבער איר האָבן פראַגמאַנטיישאַן פון ליידיק קאַנעקשאַנז צווישן פליסנדיק באָונסערס.

און אין אַ זיכער מאָמענט איר קען באַמערקן אַז די 3 באַונסערז יעדער עסן זייער האַרץ מיט 100%. איר דאַרפֿן גאַנץ עטלעכע באַונסערז. פארוואס?

ווייַל איר האָבן TLS. איר האָבן אַ ינקריפּטיד קשר. און אויב איר בענטשמאַרק Postgres מיט און אָן TLS, איר וועט געפֿינען אַז די נומער פון געגרינדעט קאַנעקשאַנז פאַלן מיט כּמעט צוויי אָרדערס פון מאַגנאַטוד מיט ענקריפּשאַן ענייבאַלד, ווייַל די TLS האַנדשייק קאַנסומז קפּו רעסורסן.

און אין די שפּיץ איר קענען זען גאַנץ אַ ביסל קריפּטאָגראַפיק פאַנגקשאַנז וואָס זענען עקסאַקיוטאַד ווען עס איז אַ כוואַליע פון ​​ינקאַמינג קאַנעקשאַנז. זינט אונדזער ערשטיק קענען באַשטימען צווישן אַוויילאַביליטי זאָנעס, אַ כוואַליע פון ​​ינקאַמינג קאַנעקשאַנז איז אַ פערלי טיפּיש סיטואַציע. אַז איז, פֿאַר עטלעכע סיבה די אַלט ערשטיק איז אַנאַוויילאַבאַל, די גאנצע מאַסע איז געשיקט צו אן אנדער דאַטן צענטער. זיי וועלן אַלע קומען צו זאָגן העלא צו TLS אין דער זעלביקער צייט.

און אַ גרויס נומער פון TLS האַנדשייק קען ניט מער זאָגן העלא צו באַונסער, אָבער וועט קוועטשן זיין האַלדז. רעכט צו דער טיימאַוט, די כוואַליע פון ​​ינקאַמינג קאַנעקשאַנז קען זיין אַנדאַמפּעד. אויב איר פּרובירן ווידער צו דער באַזע אָן עקספּאָונענשאַל באַקאָפף, זיי וועלן נישט קומען ווידער און ווידער אין אַ קאָוכיראַנט כוואַליע.

דאָ איז אַ ביישפּיל פון 16 פּגבאָונסערס וואָס לאָדן 16 קאָרעס מיט 100%.

מיר געקומען צו די קאַסקייד PgBouncer. דאָס איז דער בעסטער קאַנפיגיעריישאַן וואָס קענען זיין אַטשיווד אויף אונדזער מאַסע מיט באָונסער. אונדזער פונדרויסנדיק באַונסערז זענען געניצט פֿאַר TCP האַנדשייק, און ינערלעך באַונסערז זענען געניצט פֿאַר פאַקטיש פּולינג, אַזוי נישט צו פראַגמענט פונדרויסנדיק קאַנעקשאַנז צו פיל.

אין דעם קאַנפיגיעריישאַן, אַ גלאַט ריסטאַרט איז מעגלעך. איר קענען ריסטאַרט אַלע די 18 באַונסערז איינער דורך איינער. אָבער צו האַלטן אַזאַ אַ קאַנפיגיעריישאַן איז גאַנץ שווער. Sysadmins, DevOps און מענטשן וואָס זענען אַקשלי פאַראַנטוואָרטלעך פֿאַר דעם סערווער וועט נישט זיין זייער צופרידן מיט דעם אָרדענונג.

עס וואָלט ויסקומען אַז אַלע אונדזער ימפּרווומאַנץ קענען זיין פּראָמאָטעד צו עפֿענען מקור, אָבער באָונסער איז נישט זייער געזונט געשטיצט. פֿאַר בייַשפּיל, די פיייקייט צו לויפן עטלעכע PgBouncers אויף איין פּאָרט איז באגאנגען אַ חודש צוריק. עס איז געווען אַ ציען בעטן מיט דעם שטריך עטלעכע יאָר צוריק.

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

אָדער נאָך אַ בייַשפּיל. אין Postgres, איר קענען באָטל מאַכן אַ בקשה אין פּראָגרעס דורך שיקן דעם סוד צו אַ אַנדערש קשר אָן ומנייטיק אָטענטאַקיישאַן. אבער עטלעכע קלייאַנץ פשוט שיקן אַ TCP באַשטעטיק, ד"ה זיי ברעכן די נעץ קשר. וואָס וועט באָונסער טאָן? ער וועט גאָרנישט טאָן. עס וועט פאָרזעצן צו ויספירן די בקשה. אויב איר האָט באקומען אַ ריזיק נומער פון קאַנעקשאַנז וואָס האָבן באשאפן אַ דאַטאַבייס מיט קליין ריקוועס, עס איז נישט גענוג צו דיסקאַנעקט די קשר פֿון באַונסער; איר אויך דאַרפֿן צו פאַרענדיקן די ריקוועס וואָס לויפן אין די דאַטאַבייס.

דאָס איז געווען פּאַטשט און דעם פּראָבלעם איז נאָך נישט מערדזשד אין די אַפּסטרים פון באָונסער.

און אזוי זענען מיר געקומען צום מסקנא, אז מיר דארפן אן אייגענעם פארבינדונגס-פולער, וואס וועט ווערן אנטוויקלט, געפאקט, אין וועלכן מען קען שנעל פארריכטן די פראבלעמען און וואס, פארשטייט זיך, מוז מען מאַלטי-טרעדעד.

מיר שטעלן מולטיטהרעאַדינג ווי די הויפּט אַרבעט. מיר דאַרפֿן צו קענען צו שעפּן די כוואַליע פון ​​ינקאַמינג TLS קאַנעקשאַנז געזונט.

צו טאָן דאָס, מיר האָבן צו אַנטוויקלען אַ באַזונדער ביבליאָטעק גערופן Machinarium, וואָס איז דיזיינד צו באַשרייַבן די מאַשין שטאַטן פון אַ נעץ קשר ווי סאַקווענטשאַל קאָד. אויב איר קוק אין די libpq מקור קאָד, איר וועט זען עטלעכע שיין קאָמפּלעקס קאַללס וואָס קענען געבן איר אַ רעזולטאַט און זאָגן, "רופן מיר שפּעטער. רעכט איצט איך האָבן IO פֿאַר איצט, אָבער ווען די IO גייט אַוועק, איך וועט האָבן אַ מאַסע אויף די פּראַסעסער. און דאָס איז אַ מאַלטי-מדרגה סכעמע. נעץ קאָמוניקאַציע איז יוזשאַוואַלי דיסקרייבד דורך אַ שטאַט מאַשין. פילע כּללים ווי "אויב איך פריער באקומען אַ פּאַקאַט כעדער פון גרייס N, איצט איך וואַרטן פֿאַר N ביטעס," "אויב איך געשיקט אַ SYNC פּאַקאַט, איצט איך וואַרטן פֿאַר אַ פּאַקאַט מיט רעזולטאַט מעטאַדאַטאַ." דער רעזולטאַט איז אַ גאַנץ שווער, קאַונטערינטואַטיוו קאָד, ווי אויב די מייז איז קאָנווערטעד צו שורה יבערקוקן. מיר געמאכט עס אַזוי אַז אַנשטאָט פון אַ שטאַט מאַשין, די פּראָגראַמיסט דיסקרייבז די הויפּט וועג פון ינטעראַקשאַן אין די פאָרעם פון אַ פּראָסט ימפּעראַטיוו קאָד. עס איז נאָר אַז אין דעם ימפּעראַטיוו קאָד איר דאַרפֿן צו אַרייַנלייגן ערטער ווו די דורכפירונג סיקוואַנס דאַרף זיין ינטעראַפּטיד דורך ווארטן פֿאַר דאַטן פון די נעץ, און די דורכפירונג קאָנטעקסט צו אן אנדער קאָרוטינע (גרין פאָדעם). דער צוגאַנג איז ענלעך צו די פאַקט אַז מיר שרייַבן די מערסט דערוואַרט וועג אין די מייז אין אַ רודערן, און דעריבער לייגן צווייגן צו עס.

ווי אַ רעזולטאַט, מיר האָבן איין פאָדעם וואָס TCP אָננעמען און ראָונד-ראָבין פּאַסיז די TPC פֿאַרבינדונג צו פילע טוערס.

אין דעם פאַל, יעדער קליענט קשר שטענדיק לויפט אויף איין פּראַסעסער. און דאָס אַלאַוז איר צו מאַכן עס קאַש-פרייַנדלעך.

און אין אַדישאַן, מיר האָבן אַ ביסל ימפּרוווד די זאַמלונג פון קליין פּאַקיץ אין איין גרויס פּאַקאַט אין סדר צו באַפרייַען די סיסטעם טקפּ אָנלייגן.

אין אַדישאַן, מיר האָבן ימפּרוווד טראַנסאַקטיאָנאַל פּאָאָלינג אין דעם זינען אַז אָדיססיי, ווען קאַנפיגיערד, קענען שיקן CANCEL און ROLLBACK אין די געשעעניש פון אַ נעץ קשר דורכפאַל, ד"ה אויב קיין איינער איז ווארטן פֿאַר אַ בקשה, אָדיססיי וועט זאָגן די דאַטאַבייס נישט צו פּרובירן צו מקיים די בקשה אַז קען וויסט טייַער רעסורסן.

און ווען מעגלעך, מיר האַלטן קאַנעקשאַנז צו דער זעלביקער קליענט. דאָס אַוווידז צו ריינסטאַל אַפּלאַקיישאַן_נאַמע_אַדד_האָסט. אויב דאָס איז מעגלעך, מיר טאָן ניט האָבן צו באַשטעטיק די פּאַראַמעטערס וואָס זענען דארף פֿאַר דיאַגנאָסטיקס.

מיר אַרבעטן אין די אינטערעסן פון Yandex.Cloud. און אויב איר נוצן געראטן PostgreSQL און האָבן אַ קאַנעקשאַן פּאָאָלער אינסטאַלירן, איר קענען שאַפֿן לאַדזשיקאַל רעפּלאַקיישאַן אַוטווערד, ד"ה לאָזן אונדז, אויב איר ווילט, ניצן לאַדזשיקאַל רעפּלאַקיישאַן. באַונסער וועט נישט באַפרייַען די לאַדזשיקאַל רעפּלאַקיישאַן לויפן אַרויס.

דאָס איז אַ ביישפּיל פון באַשטעטיקן לאַדזשיקאַל רעפּלאַקיישאַן.

אין אַדישאַן, מיר האָבן שטיצן פֿאַר גשמיות רעפּלאַקיישאַן אַוטווערד. אין די קלאָוד, פון קורס, דאָס איז אוממעגלעך, ווייַל דער קנויל וועט געבן איר צו פיל אינפֿאָרמאַציע וועגן זיך. אָבער אין דיין ינסטאַליישאַנז, אויב איר דאַרפֿן פיזיש רעפּלאַקיישאַן דורך די קשר פּולער אין אָדיססיי, דאָס איז מעגלעך.

Odyssey האט גאָר קאַמפּאַטאַבאַל מאָניטאָרינג מיט PgBouncer. מיר האָבן די זעלבע קאַנסאָול וואָס לויפט כּמעט אַלע די זעלבע קאַמאַנדז. אויב עפּעס איז פעלנדיק, שיקן אַ ציען בעטן, אָדער בייַ מינדסטער אַן אַרויסגעבן אויף GitHub, און מיר וועלן פאַרענדיקן די נייטיק קאַמאַנדז. אָבער מיר האָבן שוין די הויפּט פאַנגקשאַנאַליטי פון די PgBouncer קאַנסאָול.

און, פון קורס, מיר האָבן טעות פאָרווערדינג. מיר וועלן צוריקקומען די טעות געמאלדן דורך די דאַטאַבייס. איר וועט באַקומען אינפֿאָרמאַציע וועגן וואָס איר זענט נישט אַרייַנגערעכנט אין די דאַטאַבייס, און ניט נאָר אַז איר זענט נישט אַרייַנגערעכנט אין עס.

דער שטריך איז פאַרקריפּלט אין פאַל איר דאַרפֿן 100% קאַמפּאַטאַבילאַטי מיט PgBouncer. מיר קענען ביכייוו די זעלבע וועג ווי באַונסער, נאָר צו זיין אויף דער זיכער זייַט.

אַנטוויקלונג

עטלעכע ווערטער וועגן די אָדיססיי מקור קאָד.

https://github.com/yandex/odyssey/pull/66

פֿאַר בייַשפּיל, עס זענען "פּאַזע / נעמענ זיכ ווידער" קאַמאַנדז. זיי זענען יוזשאַוואַלי געניצט צו דערהייַנטיקן די דאַטאַבייס. אויב איר דאַרפֿן צו דערהייַנטיקן Postgres, איר קענען פּויזע עס אין די קאַנעקשאַן פּאָאָלער, טאָן pg_upgrade, און דאַן נעמענ זיכ ווידער. און פֿון דעם קליענט ס זייַט, עס וועט קוקן ווי אויב די דאַטאַבייס איז פשוט סלאָוינג אַראָפּ. די פאַנגקשאַנאַליטי איז געבראכט צו אונדז דורך מענטשן פון די קהל. זי איז נישט פאַרפרוירן נאָך, אָבער באַלד אַלץ וועט זיין. (שוין פארפרוירן)

https://github.com/yandex/odyssey/pull/73 — שוין פארפרוירן

אין אַדישאַן, איינער פון די נייַע פֿעיִקייטן אין PgBouncer איז שטיצן פֿאַר SCRAM אָטענטאַקיישאַן, וואָס איז אויך געבראכט צו אונדז דורך אַ מענטש וואָס טוט נישט אַרבעטן אין Yandex.Cloud. ביידע זענען קאָמפּלעקס פאַנגקשאַנאַליטי און וויכטיק.

דעריבער, איך וואָלט ווי צו זאָגן איר פון וואָס אָדיססיי איז געמאכט, אין פאַל איר אויך ווילן צו שרייַבן אַ ביסל קאָד איצט.

איר האָבן די אָדיססיי מקור באַזע, וואָס רילייז אויף צוויי הויפּט לייברעריז. די קיווי ביבליאָטעק איז אַן ימפּלאַמענטיישאַן פון די Postgres אָנזאָג פּראָטאָקאָל. דאָס איז, געבוירן פּראָטאָ 3 פון Postgres איז נאָרמאַל אַרטיקלען וואָס פראָנט-ענדז און צוריק-ענדז קענען וועקסל. זיי זענען ימפּלאַמענאַד אין די קיווי ביבליאָטעק.

די מאַשינאַריום ביבליאָטעק איז אַ פאָדעם ימפּלאַמענטיישאַן ביבליאָטעק. א קליין פראַגמענט פון דעם מאַשינאַריום איז געשריבן אין פֿאַרזאַמלונג שפּראַך. אָבער טאָן ניט דערשרעקן, עס זענען בלויז 15 שורות.

אָדיססיי אַרקאַטעקטשער. עס איז אַ הויפּט מאַשין אויף וואָס קאָראָוטינעס לויפן. דער מאַשין ימפּלאַמאַנץ אַקסעפּטינג ינקאַמינג טקפּ קאַנעקשאַנז און דיסטריביוטינג זיי צווישן טוערס.

א האַנדלער פֿאַר עטלעכע קלייאַנץ קענען אַרבעטן אין איין אַרבעטער. דער הויפּט פאָדעם אויך לויפט די קאַנסאָול און די פּראַסעסינג פון קראַנע טאַסקס צו ויסמעקן קאַנעקשאַנז וואָס זענען ניט מער דארף אין די בעקן.

אָדיססיי איז טעסטעד מיט די נאָרמאַל Postgres פּרובירן סוויט. מיר נאָר לויפן ינסטאַלירן-טשעק דורך באָונסער און דורך Odyssey, מיר באַקומען אַ נאַל דיוו. עס זענען עטלעכע טעסץ שייך צו דאַטע פאָרמאַטטינג וואָס טאָן ניט דורכגיין פּונקט די זעלבע אין באָונסער און אין אָדיססיי.

אין דערצו, עס זענען פילע דריווערס וואָס האָבן זייער אייגענע טעסטינג. און מיר נוצן זייער טעסץ צו פּרובירן די אָדיססיי.

אין אַדישאַן, רעכט צו אונדזער קאַסקייד קאַנפיגיעריישאַן, מיר האָבן צו פּרובירן פאַרשידן באַנדאַלז: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey צו זיין זיכער אַז אויב אָדיססיי ענדיקט זיך אין קיין פון די פּאַרץ אין די קאַסקייד, עס אויך נאָך אַרבעט ווי מיר דערוואַרטן.

גראַבליע

מיר נוצן אָדיססיי אין פּראָדוקציע. און עס וואָלט נישט זיין שיין אויב איך געזאגט אַז אַלץ נאָר אַרבעט. ניין, דאָס איז, יאָ, אָבער ניט שטענדיק. פֿאַר בייַשפּיל, אין פּראָדוקציע אַלץ נאָר געארבעט, דעמאָלט אונדזער פרענדז פון PostgreSQL Professional געקומען און געזאגט אַז מיר האָבן אַ זכּרון רינען. זיי זענען טאַקע געווען, מיר קערעקטאַד זיי. אבער עס איז געווען פּשוט.

דערנאָך מיר דיסקאַווערד אַז די קאַנעקשאַן פּאָאָלער האט ינקאַמינג TLS קאַנעקשאַנז און אַוטגאָוינג TLS קאַנעקשאַנז. און קאַנעקשאַנז דאַרפן קליענט סערטיפיקאַץ און סערווער סערטיפיקאַץ.

באַונסער און אָדיססיי סערווער סערטיפיקאַץ זענען ריליימד דורך זייער פּקאַטשע, אָבער קליענט סערטיפיקאַץ טאָן ניט דאַרפֿן צו זיין רילייינג פֿון פּקאַטשע, ווייַל אונדזער סקאַלאַבלע אָדיססיי לעסאָף לויפט אין די סיסטעם פאָרשטעלונג פון לייענען דעם באַווייַזן. דאָס איז געווען אַ יבערראַשן צו אונדז, ווייַל עס האט נישט נעמען אים לאַנג צו אַנטקעגנשטעלנ זיך. אין ערשטער עס סקיילד לינעאַרלי, אָבער נאָך 20 ינקאַמינג סיימאַלטייניאַס קאַנעקשאַנז דעם פּראָבלעם געוויזן זיך.

פּלאַגאַבלע אָטענטאַקיישאַן מעטאַד איז די פיייקייט צו אָטענטאַקירן ניצן די געבויט-אין Lunux מכשירים. אין PgBouncer עס איז ימפּלאַמענאַד אין אַזאַ אַ וועג אַז עס איז אַ באַזונדער פאָדעם צו וואַרטן פֿאַר אַ ענטפער פון PAM און עס איז אַ הויפּט PgBouncer פאָדעם וואָס סערוויס די קראַנט קשר און קענען פרעגן זיי צו לעבן אין די PAM פאָדעם.

מיר האבן נישט ינסטרומענט דעם פֿאַר איין פּשוט סיבה. מיר האָבן אַ פּלאַץ פון פֿעדעם. פארוואס טאָן מיר דאַרפֿן דאָס?

דאָס קען לעסאָף מאַכן פּראָבלעמס אַז אויב איר האָבן PAM אָטענטאַקיישאַן און ניט-PAM אָטענטאַקיישאַן, אַ גרויס כוואַליע פון ​​PAM אָטענטאַקיישאַן קענען באטייטיק פאַרהאַלטן די ניט-PAM אָטענטאַקיישאַן. דאָס איז איינער פון די זאכן וואָס מיר האָבן נישט פאַרפעסטיקט. אבער אויב איר ווילן צו פאַרריכטן עס, איר קענען טאָן דאָס.

אן אנדער גראַבליע איז געווען אַז מיר האָבן איין פאָדעם וואָס אַקסעפּץ אַלע ינקאַמינג קאַנעקשאַנז. און דערנאָך זיי זענען טראַנספערד צו די אַרבעטער בעקן, ווו די TLS האַנדשייק וועט נעמען אָרט.

דנאָ שורה, אויב איר האָבן אַ קאָוכיראַנט כוואַליע פון ​​20 נעץ קאַנעקשאַנז, זיי וועלן אַלע זיין אנגענומען. און אויף דער קליענט זייַט, libpq וועט אָנהייבן ריפּאָרטינג טיימאַוץ. דורך פעליקייַט עס מיינט צו זיין 000 סעקונדעס.

אויב זיי אַלע קענען נישט אַרייַן די דאַטאַבייס אין דער זעלביקער צייט, זיי קענען נישט אַרייַן די דאַטאַבייס, ווייַל אַלע דעם קענען זיין באדעקט דורך ניט-עקספּאָונענטיאַל ריטריי.

מיר געקומען צו די מסקנא אַז מיר קאַפּיד די סכעמע פֿון PgBouncer דאָ מיט די פאַקט אַז מיר האָבן גערגל די נומער פון TCP קאַנעקשאַנז צו וואָס מיר אָננעמען.

אויב מיר זען אַז מיר אָננעמען קאַנעקשאַנז, אָבער זיי לעסאָף טאָן ניט האָבן צייט צו כאַנדשייק, מיר שטעלן זיי אין אַ ריי אַזוי אַז זיי טאָן ניט וויסט קפּו רעסורסן. דאָס פירט צו דעם פאַקט אַז אַ סיימאַלטייניאַס כאַנדשייק קען נישט זיין דורכגעקאָכט פֿאַר אַלע קאַנעקשאַנז וואָס זענען אנגעקומען. אָבער אין מינדסטער עמעצער וועט אַרייַן די דאַטאַבייס, אפילו אויב די מאַסע איז גאַנץ שווער.

ראָאַדמאַפּ

וואָס וואָלט איר ווי צו זען אין דער צוקונפֿט אין אָדיססיי? וואָס זענען מיר גרייט צו אַנטוויקלען זיך און וואָס טאָן מיר דערוואַרטן פון די קהל?

זינט אויגוסט 2019.

דאָס איז ווי די אָדיססיי ראָאַדמאַפּ געקוקט ווי אין אויגוסט:

• מיר געוואלט SCRAM און PAM אָטענטאַקיישאַן.
• מיר געוואלט צו פאָרווערדיד לייענען ריקוועס צו סטאַנדביי.
• איך וואָלט ווי אַן אָנליין ריסטאַרט.
• און די פיייקייט צו פּויזע אויף די סערווער.

העלפט פון דעם ראָאַדמאַפּ איז געענדיקט, און נישט דורך אונדז. און דאָס איז גוט. אַזוי לאָזן ס דיסקוטירן וואָס בלייבט און לייגן מער.

וועגן פאָרויס לייענען-בלויז קוויריז צו סטאַנדביי? מיר האָבן רעפּלאַקאַז וואָס וועט פשוט היץ די לופט אָן עקסאַקיוטינג ריקוועס. מיר דאַרפֿן זיי צו צושטעלן פאַילאָווער און סוויטטשאָווער. אין פאַל פון פּראָבלעמס אין איינער פון די דאַטן סענטערס, איך וואָלט ווי צו פאַרנעמען זיי מיט עטלעכע נוציק אַרבעט. ווייַל מיר קענען נישט קאַנפיגיער די זעלבע הויפט פּראַסעסערז, דער זעלביקער זכּרון דיפערענטלי, ווייַל אַנדערש רעפּלאַקיישאַן וועט נישט אַרבעטן.

אין פּרינציפּ, אין Postgres, סטאַרטינג פון 10, עס איז מעגלעך צו ספּעציפיצירן session_attrs ווען קאַנעקטינג. איר קענען רשימה אַלע די דאַטאַבייס מחנות אין די קשר און זאָגן וואָס איר גיין צו די דאַטאַבייס: שרייַבן אָדער לייענען בלויז. און דער שאָפער זיך וועט אויסקלייַבן דער ערשטער באַלעבאָס אין דער רשימה וואָס ער לייקס בעסטער, וואָס פולפילז די רעקווירעמענץ פון session_attrs.

אָבער די פּראָבלעם מיט דעם צוגאַנג איז אַז עס קען נישט קאָנטראָלירן די רעפּלאַקיישאַן אָפּשטיי. איר קען האָבן עטלעכע רעפּליקע וואָס איז לאַגד פֿאַר אַ אַנאַקסעפּטאַבאַל צייט פֿאַר דיין דינסט. אין סדר צו געבן פול-פיטשערד דורכפירונג פון לייענען קוויריז אויף אַ רעפּליקע, מיר יסענשאַלי דאַרפֿן צו שטיצן אָדיססיי ס פיייקייט צו נישט לויפן ווען עס קענען ניט זיין לייענען.

אָדיססיי מוזן גיין צו די דאַטאַבייס פון צייט צו צייט און פרעגן פֿאַר די רעפּלאַקיישאַן ווייַטקייט פון די ערשטיק. און אויב עס האט ריטשט די שיעור ווערט, טאָן ניט לאָזן נייַ ריקוועס אין די דאַטאַבייס, זאָגן דעם קליענט אַז עס דאַרף צו אָנהייבן קאַנעקשאַנז און, עפשער, אויסקלייַבן אן אנדער באַלעבאָס צו ויספירן ריקוועס. דאָס וועט לאָזן די דאַטאַבייס געשווינד ומקערן די רעפּלאַקיישאַן אָפּשטיי און צוריקקומען ווידער צו ריספּאַנד מיט אַ בקשה.

עס איז שווער צו געבן אַ צייט ראַם פֿאַר ימפּלאַמענטיישאַן, ווייַל עס איז אָפֿן מקור. אָבער, איך האָפֿן, נישט 2,5 יאָר ווי מיין חברים פון PgBouncer. דאָס איז דער שטריך וואָס איך וואָלט ווי צו זען אין די אָדיססיי.

אין די קהילה, מענטשן געפרעגט וועגן שטיצן פֿאַר די צוגעגרייט דערקלערונג. איצט איר קענען מאַכן אַ צוגעגרייט ויסזאָגונג אין צוויי וועגן. ערשטער, איר קענען ויספירן די SQL באַפֿעל, ניימלי "צוגעגרייט". אין סדר צו פֿאַרשטיין דעם SQL באַפֿעל, מיר דאַרפֿן צו לערנען צו פֿאַרשטיין די SQL אויף די באַונסער זייַט. דאָס וואָלט זיין אַן אָוווערקיל, ווייַל עס איז אָוווערקיל, ווייַל מיר דאַרפֿן די גאנצע פּאַרסער. מיר קענען נישט פּאַרס יעדער SQL באַפֿעל.

אָבער עס איז אַ צוגעגרייט ויסזאָגונג אויף דער אָנזאָג פּראָטאָקאָל מדרגה אויף פּראָטאָ3. און דאָס איז דער אָרט ווען די אינפֿאָרמאַציע אַז אַ צוגעגרייט ויסזאָגונג איז באשאפן קומט אין אַ סטראַקטשערד פאָרעם. און מיר קען שטיצן די פארשטאנד אַז אויף עטלעכע סערווער קשר דער קליענט געבעטן צו שאַפֿן צוגעגרייט סטייטמאַנץ. און אפילו אויב די טראַנסאַקטיאָן איז פֿאַרמאַכט, מיר נאָך דאַרפֿן צו האַלטן קאַנעקטיוויטי צווישן די סערווער און דעם קליענט.

אבער דאָ אַ דיסקרעפּאַנסי אין די דיאַלאָג ערייזאַז, ווייַל עמעצער זאגט אַז איר דאַרפֿן צו פֿאַרשטיין וואָס מין פון צוגעגרייט סטייטמאַנץ דער קליענט באשאפן און טיילן די סערווער פֿאַרבינדונג צווישן אַלע קלייאַנץ וואָס באשאפן דעם סערווער קשר, ד"ה וואס באשאפן אַזאַ אַ צוגעגרייט ויסזאָגונג.

Andres Freund האט געזאגט אַז אויב אַ קליענט קומט צו איר וואָס האט שוין באשאפן אַזאַ אַ צוגעגרייט ויסזאָגונג אין אן אנדער סערווער קשר, מאַכן עס פֿאַר אים. אָבער עס מיינט אַ ביסל פאַלש צו ויספירן קוויריז אין די דאַטאַבייס אַנשטאָט פון דעם קליענט, אָבער פֿון די פונט פון מיינונג פון די דעוועלאָפּער וואָס שרייבט דעם פּראָטאָקאָל פֿאַר ינטעראַקטינג מיט די דאַטאַבייס, עס וואָלט זיין באַקוועם אויב ער איז נאָר געגעבן אַ נעץ פֿאַרבינדונג אין וואָס עס איז אַזאַ אַ צוגעגרייט אָנפֿרעג.

און נאָך איין שטריך וואָס מיר דאַרפֿן צו ינסטרומענט. מיר איצט האָבן מאָניטאָרינג קאַמפּאַטאַבאַל מיט PgBouncer. מיר קענען צוריקקומען די דורכשניטלעך אָנפֿרעג דורכפירונג צייט. אבער די דורכשניטלעך צייט איז די דורכשניטלעך טעמפּעראַטור אין די שפּיטאָל: עטלעכע זענען קאַלט, עטלעכע זענען וואַרעם - אין דורכשניטלעך, אַלעמען איז געזונט. עס איז נישט אמת.

מיר דאַרפֿן צו ינסטרומענט שטיצן פֿאַר פּערסענטיילז, וואָס וואָלט אָנווייַזן אַז עס זענען פּאַמעלעך פֿראגן וואָס זענען וויסט רעסורסן און וואָלט מאַכן מאָניטאָרינג מער פּאַסיק.

די מערסט וויכטיק זאַך איז אַז איך ווילן ווערסיע 1.0 (ווערסיע 1.1 איז שוין באפרייט). דער פאַקט איז אַז Odyssey איז איצט אין ווערסיע 1.0rc, ד"ה מעלדונג קאַנדידאַט. און אַלע די פראבלעמען וואָס איך ליסטעד זענען פאַרפעסטיקט מיט פּונקט דער זעלביקער ווערסיע, אַחוץ די זכּרון רינען.

וואָס וועט ווערסיע 1.0 מיינען פֿאַר אונדז? מיר ראָולינג אויס אָדיססיי צו אונדזער באַסעס. עס איז שוין פליסנדיק אויף אונדזער דאַטאַבייסיז, אָבער ווען עס ריטשאַז די פונט פון 1 ריקוועס פּער סעקונדע, מיר קענען זאָגן אַז דאָס איז די מעלדונג ווערסיע און דאָס איז אַ ווערסיע וואָס קענען זיין גערופֿן 000.

עטלעכע מענטשן אין די קהל האָבן געבעטן אַז ווערסיע 1.0 ינקלודז פּויזע און SCRAM. אָבער דאָס וועט מיינען אַז מיר וועלן דאַרפֿן צו ראָולינג די ווייַטער ווערסיע צו פּראָדוקציע, ווייַל ניט SCRAM אָדער פּויזע זענען נאָך געהרגעט. אָבער, רובֿ מסתּמא, דעם אַרויסגעבן וועט זיין ריזאַלווד גאַנץ געשווינד.

איך ווארט אויף דיין פארלאנג. איך וואָלט אויך ווי צו הערן וואָס פּראָבלעמס איר האָט מיט באָונסער. זאל ס דיסקוטירן זיי. אפֿשר מיר קענען ינסטרומענט עטלעכע פאַנגקשאַנז וואָס איר דאַרפֿן.

דאָס איז דער סוף פון מיין טייל, איך וואָלט ווי צו הערן צו איר. אדאנק!

שאלות

אויב איך שטעלן מיין אייגענע אַפּלאַקיישאַן_נאַמע, וועט עס זיין פאָרווערדיד ריכטיק, אַרייַנגערעכנט טראַנסאַקטיאָן פּולינג אין אָדיססיי?

אָדיססיי אָדער באַונסער?

אין אָדיססיי. אין באַונסער עס איז ארלנגעווארפן.

מיר וועלן מאַכן אַ גאַנג.

און אויב מיין פאַקטיש קשר דזשאַמפּס אויף אנדערע קאַנעקשאַנז, וועט עס זיין טראַנסמיטטעד?

מיר וועלן מאַכן אַ סכום פון אַלע פּאַראַמעטערס וואָס זענען ליסטעד אין דער רשימה. איך קען נישט זאָגן אויב אַפּלאַקיישאַן_נאַמע איז אין דער רשימה. איך מיין אז איך האב אים דארט געזעהן. מיר וועלן שטעלן אַלע די זעלבע פּאַראַמעטערס. מיט איין בקשה, דער גאַנג וועט טאָן אַלץ וואָס איז געווען אינסטאַלירן דורך דעם קליענט בעשאַס די סטאַרטאַפּ.

דאַנקען דיר, אַנדריי, פֿאַר דעם באַריכט! גוט באַריכט! איך בין צופרידן אַז אָדיססיי איז דעוועלאָפּינג פאַסטער און פאַסטער יעדער מינוט. איך וויל אזוי ווייטער ממשיך זיין. מיר האָבן שוין געבעטן איר צו האָבן אַ מולטי דאַטן-מקור קשר אַזוי אַז אָדיססיי קענען פאַרבינדן צו פאַרשידענע דאַטאַבייסיז סיימאַלטייניאַסלי, ד"ה אַ בעל שקלאַף, און דעמאָלט אויטאָמאַטיש פאַרבינדן צו אַ נייַ בעל נאָך פיילאָווער.

יא, איך ווי צו געדענקען דעם דיסקוסיע. איצט עס זענען עטלעכע סטאָרידזש. אבער עס איז קיין סוויטשינג צווישן זיי. אויף אונדזער זייַט, מיר מוזן אָפּשאַצן די סערווער אַז עס איז נאָך לעבעדיק און פֿאַרשטיין אַז אַ פיילאָווער איז פארגעקומען, וואָס וועט רופן pg_recovery. איך האב א סטאנדארט וועג צו פארשטיין אז מיר זענען נישט געקומען צום בעל. און זאָל מיר עפעס פֿאַרשטיין פון די מיסטייקס אָדער וואָס? דאָס הייסט, דער געדאַנק איז אינטערעסאַנט, מע רעדט וועגן אים. שרייב מער באַמערקונגען. אויב איר האָבן טוערס וואָס וויסן C, דאָס איז גרויס.

די אַרויסגעבן פון סקיילינג אַריבער רעפּלאַקאַז איז אויך פון אינטערעס צו אונדז, ווייַל מיר ווילן צו מאַכן די אַדאַפּשאַן פון רעפּליקייטיד קלאַסטערז ווי פּשוט ווי מעגלעך פֿאַר אַפּלאַקיישאַן דעוועלאָפּערס. אבער דאָ איך וואָלט ווי מער באַמערקונגען, ד"ה פּונקט ווי צו טאָן עס, ווי צו טאָן עס געזונט.

די קשיא איז אויך וועגן רעפּלאַקאַז. עס טורנס אויס אַז איר האָבן אַ בעל און עטלעכע רעפּלאַקאַז. און עס איז קלאָר אַז זיי גיין צו די רעפּליקע ווייניקער אָפט ווי צו די בעל פֿאַר קאַנעקשאַנז, ווייַל זיי קען האָבן דיפעראַנסיז. איר האָט געזאָגט אַז דער חילוק אין די דאַטן קען זיין אַזוי אַז עס וועט נישט באַפרידיקן דיין געשעפט און איר וועט נישט גיין דאָרט ביז עס איז רעפּליקייטיד. אין דער זעלביקער צייט, אויב איר האָט נישט גיין דאָרט פֿאַר אַ לאַנג צייַט, און דעמאָלט אנגעהויבן צו גיין, די דאַטן וואָס איר דאַרפֿן וועט נישט זיין גלייך בנימצא. אַז איז, אויב מיר קעסיידער גיין צו די בעל, דער קאַש דאָרט איז וואָרמד אַרויף, אָבער אין די רעפּליקע די קאַש לאַגז אַ ביסל.

יא עס איז אמת. די פּקאַטשע וועט נישט האָבן די דאַטן בלאַקס איר ווילן, די פאַקטיש קאַש וועט נישט האָבן אינפֿאָרמאַציע וועגן די טישן איר ווילן, די פּלאַנז וועט נישט האָבן פּאַרסט קוויריז, עס וועט זיין גאָרנישט.

און ווען איר האָט אַ סאָרט פון קנויל, און איר לייגן אַ נייַע רעפּליקע דאָרט, בשעת עס סטאַרץ, אַלץ איז שלעכט אין עס, דאָס הייסט עס ינקריסיז זייַן קאַש.

איך גאַט דער געדאַנק. דער ריכטיק צוגאַנג וואָלט זיין צו לויפן אַ קליין פּראָצענט פון פֿראגן אויף די רעפּליקע ערשטער, וואָס וואָלט וואַרעמען די קאַש. בעערעך גערעדט, מיר האָבן אַ צושטאַנד אַז מיר מוזן אָפּהאַלטן הינטער דעם בעל מיט ניט מער ווי 10 סעקונדעס. און דעם צושטאַנד איז נישט אַרייַנגערעכנט אין איין כוואַליע, אָבער סמודלי פֿאַר עטלעכע קלייאַנץ.

יא, פאַרגרעסערן וואָג.

דאָס איז אַ גוטע געדאַנק. אבער ערשטער מיר דאַרפֿן צו ינסטרומענט דעם שאַטדאַון. ערשטער מיר דאַרפֿן צו קער אַוועק, און דעמאָלט מיר וועלן טראַכטן וועגן ווי צו קער אויף. דאָס איז אַ גרויס שטריך צו געבן סמודלי.

Nginx האט דעם אָפּציע slowly start אין אַ קנויל פֿאַר די סערווער. און ער ביסלעכווייַז ינקריסיז די מאַסע.

יאָ, גרויס געדאַנק, מיר וועלן פּרובירן עס ווען מיר באַקומען אַרום עס.

מקור: www.habr.com