ווי צו פאַרגרעסערן קאַנקעראַנט קאַנעקשאַנז אין אַפּאַטשי

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

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

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

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

apache2_logo

דער ערשטער זאַך צו טראַכטן וועגן איז: וואָס קאַפּאַציטעט האט מיין מאַנשאַפֿט? ווי פילע סיימאַלטייניאַס קאַנעקשאַנז קענען מיין ויסריכט שטיצן אויב איך פאָרס עס ווי פיל ווי מעגלעך? אַלע דעם דעפּענדס אויף אַ איין פאַקטאָר; RAM (Random Access Memory).

די גרעסערע די באַראַן, די גרעסערע נומער פון קאַנעקשאַנז, כאָטש עס איז קיין פאַרפעסטיקט ווערט (וואָס איז, X קלייאַנץ פֿאַר יעדער X באַראַן), דעריבער, ערשטער פון אַלע עס איז וויכטיק צו מאַכן עטלעכע קליין חשבונות אויף אונדזער וועב סערווער מיט אין סדר צו וויסן אונדזער לימאַץ.

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

ps -ylC apache2 - סאָרט: rss | וואָק '{SUM + = $ 8; איך + = 1} ענדיקן {דרוק סאַם / איך / 1024} '

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

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

ps -N -ylC apache2 - סאָרט: rss | אַווק '{SUM + = $ 8} END {print SUM / 1024}'

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

(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN

מיט דעם פאָרמולע אין האַנט, לאָזן ס ימאַדזשאַן אַז מיר האָבן אַ קאָמפּיוטער מיט 4 גיגאבייט באַראַן, דאָס הייסט 4096 מעגאבייטן און אַז אונדזער קאָמפּיוטער האט געוויזן די אַפאָרמענשאַנד רעזולטאַטן; די כעזשבן וואָלט זיין:

(4096 - 800) / 10 = 329 סיימאַלטייניאַס קאַנעקשאַנז

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

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

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

סטאַרץ סערווערס 5 מינספּאַרע סערווערס 5 מאַקספּאַרע סערווערס 10 מאַקס קליענץ 150 מאַקס ריקוועס פּערשילד 0

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

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

דער פּאַראַמעטער ServerLimit דאַרף שטענדיק זיין אַ ביסל העכער ווי די MaxClients און דאָ, ווייַל עס איז קליין פּלאַץ פֿאַר מאַנוווער, אַ שיעור פון 270. דאָס וואָלט מאַכן די מאָדולע קוק ווי דאָס:

סטאַרץ סערווערס 5 מינספּאַרע סערווערס 5 מאַקספּאַרע סערווערס 10 סערווירער לימיט 270 מאַקס קליענץ 250 מאַקס ריקוועס פּערשילד 0

איצט עס וואָלט זיין נאָר נייטיק צו ריסטאַרט די אַפּאַטשי סערוויס מיט דעם באַפֿעל: 

/etc/init.d/apache2 ריסטאַרט

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

גרעעטינגס.


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

21 באַמערקונגען, לאָזן דיין

לאָזן דיין באַמערקונג

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

*

*

  1. פאַראַנטוואָרטלעך פֿאַר די דאַטן: Miguel Ángel Gatón
  2. ציל פון די דאַטן: קאָנטראָל ספּאַם, קאָמענטאַר פאַרוואַלטונג.
  3. לעגיטימאַטיאָן: דיין צושטימען
  4. קאָמוניקאַציע פון ​​די דאַטן: די דאַטן וועט נישט זיין קאַמיונאַקייטיד צו דריט פּאַרטיעס אַחוץ דורך לעגאַל פליכט.
  5. דאַטן סטאָרידזש: דאַטאַבייס כאָוסטיד דורך Occentus Networks (EU)
  6. רעכט: צו קיין צייט איר קענט באַגרענעצן, צוריקקריגן און ויסמעקן דיין אינפֿאָרמאַציע.

  1.   זעטאַטינאָ דאָס

    דאַנקען פֿאַר דעם פּאָסטן!

    1.    דראַססילל דאָס

      איך בין צופרידן איר געפֿונען עס נוציק.

      גרעעטינגס.

  2.   מיגו אַנגעל דאָס

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

    1.    דראַססילל דאָס

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

      http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/

    2.    עדואַרדאָ דזשאַליל דאָס

      איר האָט לאַנג געבעטן אויב איר האָט נישט סאָלווע; איך האָבן אַ באַלאַנסינג סכעמע מיט אַ דריט טיילווייַז וואָס אַרבעט ווי אַ טעקע סיסטעם, איר ווייַזן די פאָלדערס וואָס זענען אין var / www / html / (אין מיין פאַל) צו די טעקע סיסטעם, אַזוי זיי טיילן די זעלבע אינפֿאָרמאַציע, און איר וועט עפשער דאַרפן אַ ווירטואַל IP אַז ריספּאַנדז. און רידערעקט צו די יפּס פון די אַפּאַטשיז, פֿאַר דעם איר קענען פאַרנעמען אַ האַפּראָקסי און אויב איר ווילט עס אין הויך אַוויילאַבילאַטי, איר קענען ויסשטימען קעעפּאַליווע אין פאַל איינער פאלט, די אנדערע פאָרזעצן צו ענטפֿערן, אָדער אויב איר שוין האָבן אַ פעלד פֿאַר די אַפּלאַקיישאַן, איר קענען וואָג מיט פונט טאָן באַקענדז צו ביידע סערווערס, פֿאַר ספּעציפיש קאַסעס אַזאַ ווי מאָדללע אָדער זיכער אַפּלאַקיישאַנז וואָס פאַרבינדן צו אַ דאַטאַבייס אין מיסקל, איר דאַרפֿן צו שאַפֿן אַ באַניצער פּער אַפּ סערווער וואָס ווייזט צו דער זעלביקער דאַטאַבייס.

  3.   שאַמאַרו דאָס

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

    1.    דראַססילל דאָס

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

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

      http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html

      גרוס

  4.   סערגיאָ ז דאָס

    זייער גוט טאָן, דאַנקען דיר זייער פיל!

    1.    דראַססילל דאָס

      א גרויסן ש 'כח! איך האָפֿן איר האָבן שוין קענען צו נוצן דעם.

  5.   בלאַזן דאָס

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

    1.    דראַססילל דאָס

      עס איז קיין שטיל קרעטין קשיא. די אמת איז אַז דורך ינקריסינג די נומער פון סיימאַלטייניאַס קאַנעקשאַנז, מיר פאָרט Apache קעגן DDOS אנפאלן טייל ווייַל איר דאַרפֿן צו נעמען אין חשבון אַז די נומער פון מאַקסימום סיימאַלטייניאַס קאַנעקשאַנז געגרינדעט אויף די סערווער איז די נומער פון גאַנץ מאַקסימום קאַנעקשאַנז, נישט די קומענדיק פֿון אַ איין באַניצער. אין דעם אָנהייב, מיר קען בלויז שטיצן 150 סיימאַלטייניאַס קאַנעקשאַנז (צי זיי זענען קאַנעקשאַנז פון אַ לאַדזשיטאַמאַט מקור אָדער נישט), איצט מיר קענען ציילן אויף ווי פילע ווי אונדזער סערווער שטיצט, און ריקווייערז אַ גרעסערע נומער פון קאַנעקשאַנז אין דער זעלביקער צייט דינען. דאָך, ינקריסינג די מאַקסימום נומער פון קאַנעקשאַנז איז נישט אַ וועג צו באַשיצן קעגן דעם טיפּ פון באַפאַלן, אָבער גאַנץ פירעוואַלל פּאַלאַסיז האָבן צו זיין ימפּלאַמענאַד. אויב, למשל, די וועב סערוויס וואָס איר ווילט צו זיין יקספּאָוזד צו דער אינטערנעץ, אַ זיכערהייט מאָס וואָס קען זיין ימפּלאַמענאַד איז די דערצו פון די שורות צו אונדזער פיירוואַל:

      יפּטאַבלעס -אַ אַרייַנשרייַב -פּ טקפּ -סין -פּאָרט 80 -ם קאָננלימיט –קאָננלימיט-אַרויף צו 10 -ם שטאַט-שטאַט נייַ

      iptables -A INPUT -p tcp –דעפּאָרט 80 -m שטאַט –state ESTABLISHED, RELATED -j אַקסעפּט

      יפּטאַבלעס -אַ אַרייַנשרייַב -פּ טקפּ -פּאָרט 80 -דזש דראַפּ

      1.    בלאַזן דאָס

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

    2.    דראַססילל דאָס

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

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

      גרעעטינגס.

  6.   עליאָטימע 3000 דאָס

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

  7.   Bruno cascio דאָס

    פייַן פּאָסטן @ דאַסראַסיל!

    איך געוואלט צו שטיצן עפּעס טאָמער מער סטאַטיסטיש ווי קאַנפיגיעריישאַן.
    כאָטש די יזיאַסט און פאַסטאַסט וועג צו רעכענען די קאַנסאַמשאַן פּאַראַמעטער איז מיט די דורכשניטלעך, טאָמער מיר קען זיין שטרענגער און נוצן די "מידיאַן" אַנשטאָט פון די "מיטל". וואָס וואָלט ראַטעווען אונדז? אַז די נומערן דרייען זיך אין פאַל אַ פֿאַרבינדונג קאַנסומד אַ פּלאַץ פון זכּרון. פֿאַר בייַשפּיל, רעכן די פאלגענדע קלייאַנץ וואָס פאַרנוצן די פאלגענדע וואַלועס אין די זיקאָרן אַפּאַראַט זיי וועלן (KB, MB, MiB, עטק):

    10, 15, 150, 5, 7, 10, 11, 12

    די דורכשניטלעך וואָלט געבן בעערעך ~ 30

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

    5, 7, 10, 10, 11, 12, 15, 150

    אַזוי אונדזער דורכשניטלעך וואָלט זיין: 8/2 = 4 וואָס איז ~ 10

    דאָ איר קענען זען אַז קיין ענין ווי משוגע די עקסטרעם קען זיין, עס וועט שטענדיק געבן אונדז אַ מער רעאַליסטיש ווערט. אויב מיר לייגן אַ קונה וואָס קאַנסומז 200, אונדזער מידיאַן וועט זיין 11, און די דורכשניטלעך קען גיין צו …….

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

    אַרומנעמען מענטשן לינוקסעראַ 🙂

  8.   קאַרלאָס דאָס

    העלא, איך האָבן געהאט אַ פּראָבלעם אויף מיין דעדאַקייטאַד סערווירער, און דאָס איז אַז יעדער מאָל ווען די נומער פון בעערעך 250 מענטשן אָנליין אַפּראָוטשיז, לויט Google Analytics אין פאַקטיש צייט, מיין סערווירער ווי עס קאַלאַפּסיז און די קשר ווערט פּאַמעלעך ביז עס פאַלן די קשר צו די וועבזייטל און קיינמאָל ופּלאָאַדס מער ווי די נומער פון וסערס אָנליין, אָבער ווען איך זען די פאָרשטעלונג פון די דעדאַקייטאַד סערווירער וואָס איז 8 גב באַראַן, עס ווייזט 10% פון נוצן, די קפּו: 5% פון די נוצן און די שווער דיסק: 1.99% פון נוצן.
    קענען איר העלפֿן מיר? איך קען ניט געפֿינען וואָס צו טאָן, איז די לייזונג צו טאָן די סטעפּס?

    1.    דראַססילל דאָס

      גוטע קאַרלאָס.

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

      גרעעטינגס.

      1.    קאַרלאָס דאָס

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

    2.    דראַססילל דאָס

      דער דאַטאַבייס באַגריף איז גאַנץ אָפֿן; ניצן מיסקל איז נישט די זעלבע ווי פּאָסטגרעס (פֿאַר בייַשפּיל). דאָך, איך קען נישט אַלע דאַטאַבייסיז; איך האָב געפרוווט מיסקל און פּאָסטגרעס, און די פאַרגרעסערן אין די סיימאַלטייניאַס קאַנעקשאַנז אין די וואָלט זיין באזירט אויף די פּאַראַמעטער מאַקסימום קאַנעקשאַנז; אַפּטאַמאַזיישאַן פון מיסקל וואָלט זיין דורכגעקאָכט אין /etc/my.conf און די פּאַראַמעטער מאַקס קאַנעקשאַנז וואָלט זיין טשיינדזשד (צווישן אנדערע). פֿאַר פּאָסטגרעס אַנשטאָט, איך האָבן אַן אַרטיקל אויף מיין בלאָג וואָס דערקלערט ווי צו אַפּטאַמייז דעם וואָס קען זיין נוציק פֿאַר איר אָדער וואָס איר קענען נוצן ווי אַ רעפֿערענץ פֿאַר דיין דאַטאַבייס:

      http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html

      גרעעטינגס.

  9.   Erickson vasquez דאָס

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

  10.   דניאל אָעדאַ דאָס

    דאנק איר פֿאַר דעם פּאָסטן.

בול (אמת)