د 2015 راپور لیږد د الیا کوسموډیمیانسکي لخوا "د پوسټ ګریس ایس کیو ایل فعالیت ښه کولو لپاره د لینکس ټوننګ"
خبرتیا: زه یادونه کوم چې دا راپور د نومبر 2015 نیټه ده - له 4 څخه ډیر کلونه تیر شوي او ډیر وخت تیر شوی. په راپور کې بحث شوی 9.4 نسخه نور ملاتړ نه کوي. په تیرو 4 کلونو کې ، د PostgreSQL 5 نوي ریلیزونه خپاره شوي ، او د لینکس کرنل 15 نسخې خوشې شوي. که تاسو دا عبارتونه بیا ولیکئ، نو تاسو به د یو بل راپور سره پای ته ورسیږئ. مګر دلته موږ د PostgreSQL لپاره د لینکس بنسټیز ټونینګ په پام کې نیسو، کوم چې نن ورځ هم اړین دی.
زما نوم Ilya Kosmodemyansky دی. زه په PostgreSQL-Consulting کې کار کوم. او اوس به زه په عمومي ډول د ډیټابیسونو او په ځانګړي توګه د PostgreSQL په اړه د لینکس سره د څه کولو په اړه لږ څه وغږیږم ، ځکه چې اصول خورا ورته دي.
موږ به د څه په اړه خبرې وکړو؟ که تاسو د PostgreSQL سره اړیکه ونیسئ، نو تر یوې اندازې پورې تاسو اړتیا لرئ چې د UNIX مدیر اوسئ. دا څه معنی ورکوي؟ که موږ Oracle او PostgreSQL پرتله کړو، نو په اوریکل کې تاسو اړتیا لرئ د 80٪ DBA ډیټابیس اډمین او 20٪ لینکس اډمین اوسئ.
د PostgreSQL سره دا یو څه ډیر پیچلی دی. د PostgreSQL سره تاسو اړتیا لرئ چې د لینکس کار کولو څرنګوالي په اړه خورا ښه پوهه ولرئ. او په ورته وخت کې، یو څه د لوکوموټیو وروسته وګرځئ، ځکه چې پدې وروستیو کې هرڅه په ښه توګه تازه شوي. او نوي دانه خوشې کیږي، او نوي فعالیت څرګندیږي، فعالیت ښه کیږي، او نور.
ولې موږ د لینکس په اړه خبرې کوو؟ په هیڅ ډول نه ځکه چې موږ د لینکس کنفرانس پیټر کې یو ، مګر ځکه چې په عصري شرایطو کې په عمومي ډول د ډیټابیس کارولو لپاره یو له خورا توجیه شوي عملیاتي سیسټمونو او په ځانګړي توګه PostgreSQL لینکس دی. ځکه چې FreeBSD، له بده مرغه، په یو څه خورا عجیب لوري کې وده کوي. او د فعالیت او ډیری نورو شیانو سره به ستونزې وي. په وینډوز کې د PostgreSQL فعالیت عموما یو جلا جدي مسله ده ، د دې حقیقت پراساس چې وینډوز د UNIX په څیر ورته شریک حافظه نلري ، پداسې حال کې چې PostgreSQL ټول پدې پورې تړلي دي ، ځکه چې دا یو څو پروسې سیسټم دی.
او زه فکر کوم چې هرڅوک د سولاریس په څیر خارجي توکو سره لږ علاقه لري ، نو راځئ چې لاړ شو.
د لینوکس عصري توزیع له 1 څخه ډیر syctl اختیارونه لري، پدې پورې اړه لري چې تاسو څنګه کرنل رامینځته کوئ. په ورته وخت کې، که موږ مختلف مغز ته وګورو، موږ کولی شو یو څه په ډیری لارو تنظیم کړو. د فایل سیسټم پیرامیټونه شتون لري چې څنګه یې نصب کړئ. که تاسو د دې د پیل کولو څرنګوالي په اړه پوښتنې لرئ: په BIOS کې څه فعال کړئ ، د هارډویر تنظیم کولو څرنګوالی ، او داسې نور.
دا یو خورا لوی حجم دی چې په څو ورځو کې بحث کیدی شي ، او په یو لنډ راپور کې نه ، مګر اوس زه به په مهمو شیانو تمرکز وکړم ، څنګه د هغه ریکونو څخه مخنیوی وکړم چې تضمین شوي چې تاسو په لینکس کې ستاسو ډیټابیس ښه کارولو څخه مخنیوی کوي که تاسو دوی سم مه کوئ. او په ورته وخت کې، یو مهم ټکی دا دی چې ډیری ډیفالټ پیرامیټونه په هغه ترتیباتو کې ندي شامل شوي چې د ډیټابیس لپاره سم دي. دا دی، د ډیفالټ په واسطه به دا خراب کار وکړي یا نه.
په لینکس کې کوم دودیز ټونینګ اهداف شتون لري؟ زه فکر کوم چې څنګه چې تاسو ټول د لینکس ادارې سره معامله کوئ ، نو د دې تشریح کولو لپاره کوم ځانګړي اړتیا نشته چې اهداف څه دي.
تاسو کولی شئ غږ کړئ:
- سی پی یو.
- حافظه.
- زېرمه.
- نور. موږ به په پای کې د ډوډۍ لپاره په دې اړه خبرې وکړو. حتی، د مثال په توګه، پیرامیټونه لکه د انرژۍ سپمولو پالیسي کولی شي په خورا غیر متوقع او خورا خوندور ډول په فعالیت اغیزه وکړي.
په عمومي ډول د PostgreSQL او ډیټابیس ځانګړتیاوې څه دي؟ ستونزه دا ده چې تاسو نشئ کولی کوم انفرادي مغز ټیک کړئ او وګورئ چې زموږ فعالیت د پام وړ ښه شوی.
هو، داسې وسایل شتون لري، مګر ډیټابیس یو پیچلی شی دی. دا د ټولو سرچینو سره اړیکه لري چې سرور یې لري او غوره کوي چې په بشپړ ډول متقابل عمل وکړي. که تاسو د کوربه OS کارولو څرنګوالي په اړه د اوریکل اوسني وړاندیزونو ته ګورئ ، نو دا به د منګولیا کاسموناټ په اړه د ټوکې په څیر وي - سپي ته خواړه ورکړئ او هیڅ شی ته لاس مه ورکوئ. راځئ چې ډیټابیس ته ټولې سرچینې ورکړو، ډیټابیس به پخپله هرڅه تنظیم کړي.
په اصولو کې، تر یوې اندازې پورې وضعیت د PostgreSQL سره ورته دی. توپیر دا دی چې ډیټابیس لاهم د دې توان نلري چې ټولې سرچینې د ځان لپاره واخلي ، د بیلګې په توګه د لینکس په کچه چیرې تاسو اړتیا لرئ دا ټول پخپله ترتیب کړئ.
اصلي مفکوره دا نه ده چې یو واحد هدف وټاکئ او د هغې سره سمون پیل کړئ، د بیلګې په توګه، حافظه، CPU یا داسې نور، مګر د کار بار تحلیل کړئ او هڅه وکړئ چې د امکان تر حده د ټروپوټ ښه کولو هڅه وکړئ ترڅو هغه بار چې ښه پروګرامرانو یې رامینځته کړی وي. زموږ لپاره، زموږ د کاروونکو په ګډون.
دلته یو انځور دی چې تشریح کړي چې دا څه دي. دلته د لینکس OS بفر شتون لري او شریکه حافظه شتون لري او د PostgreSQL شریک بفر شتون لري. PostgreSQL، د اوریکل برعکس، په مستقیم ډول یوازې د کرنل بفر له لارې کار کوي، د بیلګې په توګه، د ډیسک څخه د یوې پاڼې لپاره چې د هغې شریکې حافظې ته ورسیږي، دا باید د کرنل بفر او شاته لاړ شي، ورته ورته حالت.
ډیسکونه د دې سیسټم لاندې ژوند کوي. ما دا د ډیسک په توګه رسم کړل. په حقیقت کې، ممکن د RAID کنټرولر وي، او داسې نور.
او دا انپټ-آؤټ پوټ یو یا بل ډول د دې مسلې له لارې پیښیږي.
PostgreSQL یو کلاسیک ډیټابیس دی. دننه یوه پاڼه ده. او ټول داخل او محصول د پاڼو په کارولو سره پیښیږي. موږ د پاڼو سره په حافظه کې بلاکونه پورته کوو. او که هیڅ شی نه وي، موږ یوازې دوی لوستل، بیا په تدریجي ډول دوی د دې زیرمې څخه، د شریک بفرونو څخه ورک کیږي او بیرته په ډیسک کې پای ته رسیږي.
که چیرې موږ یو څه ځای په ځای کړو، نو ټوله پاڼه د خندا په توګه نښه کیږي. ما دوی دلته په نیلي نښه کړل. او دا پدې مانا ده چې دا پاڼه باید د بلاک ذخیره کولو سره همغږي شي. دا، کله چې موږ دا خندا وکړه، موږ په وال کې داخل شو. او په یو څه په زړه پورې شیبه کې د وخت په تیریدو سره ، د پوستې په نوم یوه پیښه راغله. او په دې لاګ کې هغه معلومات ثبت شوي چې هغه را رسیدلی و. او د دې معنی دا ده چې ټولې ناپاکې پاڼې چې دلته په دې وخت کې په دې شریک شوي بفرونو کې وې د کرنل بفر له لارې د fsync په کارولو سره د ذخیره کولو ډیسک سره همغږي شوي.
دا ولې ترسره کیږي؟ که موږ ولتاژ له لاسه ورکړو، نو موږ داسې وضعیت نه شو ترلاسه کولی چې ټول معلومات له لاسه ورکړي. دوامداره حافظه ، چې هرڅوک یې موږ ته وویل ، د ډیټابیس تیوري کې لاهم شتون لري - دا یو روښانه راتلونکی دی چې موږ یې ، البته ، هڅه کوو او موږ یې خوښوو ، مګر د اوس لپاره دوی په منفي 20 کلونو کې ژوند کوي. او البته، دا ټول باید وڅیړل شي.
او د ټرپوټ اعظمي کولو دنده په دې ټولو مرحلو کې ښه تنظیم کول دي ترڅو دا ټول په چټکۍ سره مخ په وړاندې ځي. شریکه حافظه اساسا د پاڼې زیرمه ده. په PostgreSQL کې موږ یوه انتخابي پوښتنه یا یو څه لیږلي، دا دا ډاټا د ډیسک څخه بیرته ترلاسه کوي. دوی په شریک بفرونو کې پای ته ورسیدل. په دې اساس، د دې لپاره چې ښه کار وکړي، باید ډیره حافظه وي.
د دې لپاره چې دا ټول ښه او ګړندي کار وکړي ، تاسو اړتیا لرئ په ټولو مرحلو کې عملیاتي سیسټم په سمه توګه تنظیم کړئ. او متوازن هارډویر غوره کړئ ، ځکه چې که تاسو په کوم ځای کې توازن ولرئ ، نو تاسو کولی شئ ډیر حافظه رامینځته کړئ ، مګر دا به په کافي سرعت سره خدمت نشي.
او راځئ چې د دې هرې نقطې له لارې لاړ شو.
د دې لپاره چې دا پاڼې په چټکۍ سره مخ په وړاندې لاړ شي، تاسو اړتیا لرئ چې لاندې لاسته راوړنې ترلاسه کړئ:
- لومړی، تاسو اړتیا لرئ د حافظې سره ډیر اغیزمن کار وکړئ.
- دوهم، دا لیږد کله چې د حافظې څخه پاڼې ډیسک ته ځي باید ډیر اغیزمن وي.
- او دریم، باید ښه ډیسکونه وي.
که تاسو په سرور کې 512 GB RAM لرئ او دا ټول د SATA هارډ ډرایو کې پرته له کومې زیرمې پای ته رسي ، نو د ډیټابیس ټول سرور نه یوازې کدو بدلیږي ، بلکه د SATA انٹرفیس سره کدو بدلیږي. تاسو به په مستقیم ډول دې ته ورشئ. او هیڅ شی به تاسو وژغوري.
د یادولو سره د لومړي ټکي په اړه، درې شیان دي چې کولی شي ژوند خورا ستونزمن کړي.
د دوی لومړی NUMA دی. NUMA یو شی دی چې د فعالیت ښه کولو لپاره جوړ شوی. د کاري بار پورې اړه لري، مختلف شیان مطلوب کیدی شي. او په خپل نوي اوسني بڼه کې، دا د غوښتنلیکونو لکه ډیټابیسونو لپاره خورا ښه نه دی چې په شدت سره د پاڼې کیچ شریک بفرونه کاروي.
په لنډه توګه. تاسو څنګه کولی شئ ووایاست که یو څه د NUMA سره غلط وي؟ تاسو یو ډول ناخوښه ټکان لرئ، ناڅاپه ځینې CPU ډیر بار شوی. په ورته وخت کې، تاسو په PostgreSQL کې پوښتنې تحلیل کړئ او وګورئ چې هلته ورته هیڅ شی شتون نلري. دا پوښتنې باید دومره CPU نه وي. تاسو کولی شئ دا د اوږدې مودې لپاره ونیسئ. د PostgreSQL لپاره د NUMA تنظیم کولو څرنګوالي په اړه له پیل څخه سم وړاندیز کارول اسانه دي.
رښتیا څه روان دي؟ NUMA د غیر یونیفورم حافظې لاسرسي لپاره ولاړ دی. څه خبره ده؟ تاسو یو CPU لرئ، د هغې تر څنګ یې ځایی حافظه ده. او دا حافظه یو له بل سره وصل کولی شي د نورو CPUs څخه حافظه راوباسي.
که تاسو منډې وهئ numactl --hardwareنو تاسو به دومره لوی شیټ ترلاسه کړئ. د نورو شیانو په مینځ کې به د فاصلې ساحه وي. دلته به شمیرې وي - 10-20، داسې یو څه. دا شمیرې د هپونو شمیر څخه ډیر څه ندي ترڅو دا لیرې حافظه غوره کړي او په ځایی توګه یې وکاروي. په اصل کې، یو ښه نظر. دا د یو لړ کاري بارونو لاندې فعالیت ښه کوي.
اوس تصور وکړئ چې تاسو یو CPU لرئ لومړی د هغې محلي حافظې کارولو هڅه کوئ ، بیا د یو څه لپاره د نښلولو له لارې د بلې حافظې د را ایستلو هڅه کوئ. او دا CPU ستاسو ټول PostgreSQL پاڼې کیچ ترلاسه کوي - دا دی، یو څه ګیګابایټ. تاسو تل تر ټولو ناوړه قضیه ترلاسه کوئ، ځکه چې په CPU کې معمولا په دې ماډل کې لږ حافظه شتون لري. او ټول هغه حافظه چې خدمت کیږي د دې متقابلو اړیکو له لارې تیریږي. دا ورو ورو او غمجن کیږي. او ستاسو پروسیسر چې دا نوډ خدمت کوي په دوامداره توګه ډیریږي. او د دې حافظې د لاسرسي وخت خراب، ورو دی. دا هغه حالت دی چې تاسو یې نه غواړئ که تاسو دا د ډیټابیس لپاره کاروئ.
له همدې امله، د ډیټابیس لپاره یو ډیر سم انتخاب د لینکس عملیاتي سیسټم لپاره دی ترڅو نه پوهیږي چې هلته څه تیریږي. نو دا حافظه ته لاسرسی لري لکه څنګه چې دا کوي.
ولې دغه دی؟ داسې ښکاري چې دا باید بل ډول وي. دا د یو ساده دلیل لپاره پیښیږي: موږ د پاڼې کیچ لپاره ډیری حافظې ته اړتیا لرو - لسګونه، سلګونه ګیګابایټ.
او که موږ دا ټول تخصیص کړو او خپل ډیټا هلته ذخیره کړو ، نو د کیچ کارولو لاسته راوړنه به حافظې ته د ورته پیچلي لاسرسي لاسته راوړنې څخه د پام وړ لوی وي. او موږ به پدې توګه د دې حقیقت په پرتله بې ساري ګټه پورته کړو چې موږ به د NUMA په کارولو سره حافظې ته په ډیر مؤثره توګه لاسرسی ومومئ.
له همدې امله، دا مهال دلته دوه لارې شتون لري، تر هغه چې روښانه راتلونکی رارسیدلی وي، او ډیټابیس پخپله نشي کولی معلومه کړي چې کوم CPUs روان دي او له کوم ځای څخه یو څه راوباسي.
له همدې امله، سمه لاره د NUMA په بشپړه توګه غیر فعال کول ديد مثال په توګه، کله چې ریبوټ کول. په ډیری قضیو کې، ګټونکي د داسې پراخو امرونو څخه دي چې پوښتنه یې نه کیږي چې کوم غوره دی.
یو بل اختیار شتون لري. موږ دا د لومړي په پرتله ډیر ځله کاروو ، ځکه چې کله یو پیرودونکی موږ ته د ملاتړ لپاره راځي ، د سرور ریبوټ کول د هغه لپاره لوی معامله ده. هغه هلته کاروبار لري. او دوی د NUMA له امله ستونزې تجربه کوي. له همدې امله ، موږ هڅه کوو چې دا د ریبوټ په پرتله په لږ برید کونکي لارو کې غیر فعال کړو ، مګر محتاط اوسئ چې وګورئ چې دا غیر فعال دی. ځکه چې، لکه څنګه چې تجربه ښیي، دا ښه ده چې موږ NUMA په مورنۍ PostgreSQL پروسې کې غیر فعال کړو، مګر دا اړینه نده چې دا کار وکړي. موږ باید وګورو او وګورو چې هغه واقعیا بنده شوې.
د رابرټ هاس لخوا یو ښه پوسټ شتون لري. دا د PostgreSQL ژمنو څخه یو دی. د ټولو ټیټې کچې ګیبلټس یو له کلیدي پراختیا کونکو څخه. او که تاسو د دې پوسټ لینکونه تعقیب کړئ، دوی ډیری رنګین کیسې بیانوي چې څنګه NUMA د خلکو لپاره ژوند ستونزمن کړی. وګورئ، د سیسټم مدیر چک لیست مطالعه کړئ چې زموږ د ډیټابیس د ښه کار کولو لپاره په سرور کې څه شی تنظیم کولو ته اړتیا لري. دا ترتیبات باید لیکل او چک شي، ځکه چې که نه نو دا به ډیر ښه نه وي.
مهرباني وکړئ په یاد ولرئ چې دا په ټولو ترتیباتو کې پلي کیږي چې زه به یې په اړه خبرې وکړم. مګر معمولا ډیټابیسونه د غلط زغم لپاره د ماسټر غلام حالت کې راټولیږي. په غلام باندې دا ترتیبات مه هیروئ ځکه چې یوه ورځ به تاسو حادثه وکړئ او تاسو به غلام ته لاړ شئ او دا به مالک شي.
په اضطراري حالت کې ، کله چې هرڅه خورا خراب وي ، ستاسو تلیفون په دوامداره توګه زنګ وهي او ستاسو مالک د لوی سټیک سره راځي ، تاسو به د چیک کولو په اړه فکر کولو لپاره وخت ونه لرئ. او پایلې کولی شي خورا ویجاړونکي وي.
راتلونکی ټکی لوی پاڼې دي. لوی پاڼې په جلا توګه ازموینه کول ستونزمن دي، او د دې کولو لپاره هیڅ معنی نشته، که څه هم داسې معیارونه شتون لري چې دا کار کولی شي. دوی د ګوګل لپاره اسانه دي.
څه خبره ده؟ تاسو د ډیری RAM سره خورا ګران سرور نه لرئ ، د مثال په توګه ، له 30 GB څخه ډیر. تاسو لوی پاڼې نه کاروئ. دا پدې مانا ده چې تاسو حتما د حافظې کارولو شرایطو کې ډیر سر لرئ. او دا سر له خورا خوندور څخه لرې دی.
ولې دغه دی؟ نو څه روان دي؟ عملیاتي سیسټم حافظه په کوچنیو ټوټو کې تخصیص کوي. دا خورا اسانه دی، دا څنګه په تاریخي توګه پیښیږي. او که موږ تفصیل ته لاړ شو، OS باید مجازی پتې په فزیکي کې وژباړي. او دا پروسه تر ټولو ساده نه ده، نو OS د دې عملیاتو پایله د ژباړې Lookaside Buffer (TLB) کې کیچ کوي.
او له هغه ځایه چې TLB یوه زیرمه ده، په کیچ کې موجودې ټولې ستونزې پدې حالت کې رامینځته کیږي. لومړی، که تاسو ډیری RAM لرئ او دا ټول په کوچنیو برخو کې تخصیص شوي، نو دا بفر خورا لوی کیږي. او که زیرمه لویه وي، نو د هغې له لارې لټون ورو دی. سر صحي دی او دا پخپله ځای نیسي ، د بیلګې په توګه رام د یو څه غلط لخوا مصرف کیږي. همدا اوس.
دوه - هرڅومره چې په داسې حالت کې زیرمه وده وکړي ، هومره احتمال دا دی چې تاسو به د کیچ له لاسه ورکړئ. او د دې زیرمې موثریت په چټکۍ سره کمیږي ځکه چې د هغې اندازه ډیریږي. له همدې امله، عملیاتي سیسټمونه د ساده طریقې سره راغلل. دا د اوږدې مودې لپاره په لینکس کې کارول کیږي. دا ډیر وخت دمخه په FreeBSD کې څرګند شوی. مګر موږ د لینکس په اړه خبرې کوو. دا لوی پاڼې دي.
او دلته دا باید په پام کې ونیول شي چې لوی پاڼې، د یوې مفکورې په توګه، په پیل کې د هغو ټولنو لخوا چې اوریکل او IBM پکې شامل وو، د ډیټابیس جوړونکو په کلکه فکر کاوه چې دا به د ډیټابیس لپاره هم ګټور وي.
او دا څنګه د PostgreSQL سره ملګري کیدی شي؟ لومړی، لوی پاڼې باید په لینکس کرنل کې فعالې شي.
دوهم، دوی باید په واضح ډول د sysctl پیرامیټر لخوا مشخص شي - څومره شتون لري. دلته شمیرې د ځینې زاړه سرور څخه دي. تاسو کولی شئ محاسبه کړئ چې تاسو څومره شریک شوي بفرونه لرئ ترڅو لوی پاڼې هلته فټ شي.
او که ستاسو ټول سرور PostgreSQL ته وقف شوی وي، نو یو ښه پیل ټکی دا دی چې د RAM 25٪ مشترکه بفرونو ته تخصیص کړي، یا 75٪ که تاسو ډاډه یاست چې ستاسو ډیټابیس به یقینا پدې 75٪ کې مناسب وي. د پیل ټکی. او په پام کې ونیسئ، که تاسو 256 GB رام لرئ، نو، په وینا، تاسو به د 64 GB لوی بفرونه ولرئ. نږدې د یو څه حاشیې سره محاسبه کړئ - دا شمیره باید څه ډول تنظیم شي.
د 9.2 نسخه دمخه (که زه غلط نه یم، د 8.2 نسخه راهیسې)، دا ممکنه وه چې PostgreSQL د دریمې ډلې کتابتون په کارولو سره د لوی پاڼو سره وصل کړئ. او دا باید تل ترسره شي. لومړی، تاسو د کرنل ته اړتیا لرئ ترڅو د دې وړتیا ولرئ چې لوی پاڼې په سمه توګه تخصیص کړئ. او ، دوهم ، نو هغه غوښتنلیک چې د دوی سره کار کوي کولی شي دوی وکاروي. دا به یوازې په دې ډول نه کارول کیږي. څرنګه چې PostgreSQL په سیسټم 5 سټایل کې حافظه تخصیص کړې ، نو دا د libhugetlbfs په کارولو سره ترسره کیدی شي - دا د کتابتون بشپړ نوم دی.
په 9.3 کې، د PostgreSQL فعالیت ښه شوی و کله چې د حافظې سره کار کول او د سیسټم 5 حافظې تخصیص میتود پریښودل شو. هرڅوک ډیر خوښ و ، ځکه چې که نه نو تاسو هڅه وکړئ په یوه ماشین کې دوه PostgreSQL مثالونه چل کړئ ، او هغه وايي چې زه کافي شریک حافظه نلرم. او هغه وايي چې sysctl باید سم شي. او داسې یو سیسټم شتون لري چې تاسو لاهم د ریبوټ کولو ته اړتیا لرئ، او نور په عموم کې، هرڅوک خوشحاله وو. مګر د mmap حافظې تخصیص د لویو پاڼو کارول مات کړل. زموږ ډیری پیرودونکي لوی شریک بفرونه کاروي. او موږ په کلکه سپارښتنه کوو چې 9.3 ته لاړ نه شو، ځکه چې هلته سر په ښه فیصدو کې حساب شوی.
مګر ټولنې دې ستونزې ته پاملرنه وکړه او په 9.4 کې دوی دا پیښه په ښه توګه تکرار کړه. او په 9.4 کې یو پیرامیټر په postgresql.conf کې راښکاره شو په کوم کې چې تاسو کولی شئ هڅه وکړئ، فعال یا بند کړئ.
هڅه کول ترټولو خوندي انتخاب دی. کله چې PostgreSQL پیل شي، کله چې دا شریکه حافظه تخصیص کوي، دا هڅه کوي دا حافظه د لوی پاڼو څخه واخلي. او که دا کار ونکړي، نو دا بیرته عادي انتخاب ته ځي. او که تاسو FreeBSD یا سولاریس لرئ، نو تاسو کولی شئ هڅه وکړئ، دا تل خوندي وي.
که چیرې وي، نو دا په ساده ډول نه پیل کیږي که چیرې دا د لویو پاڼو څخه غوره نشي. دلته دا دمخه دی چې څوک او څه ښه دي. مګر که تاسو هڅه کړې وي، نو بیا وګورئ چې تاسو واقعیا هغه څه لرئ چې تاسو ورته اړتیا لرئ روښانه کړئ، ځکه چې د خطا لپاره ډیر ځای شتون لري. اوس مهال دا فعالیت یوازې په لینکس کې کار کوي.
یو بل کوچنی یادونه مخکې له دې چې موږ نور لاړ شو. شفاف لوی مخونه لاهم د PostgreSQL په اړه ندي. هغه نشي کولی دوی په نورمال ډول وکاروي. او د داسې کاري بار لپاره د شفاف لوی پا pagesو سره ، کله چې د شریک حافظې لویې برخې ته اړتیا وي ، ګټې یوازې د خورا لوی حجم سره راځي. که تاسو د ټیرابایټ حافظه لرئ نو دا ممکن په لوبې کې راشي. که موږ د نورو ورځني غوښتنلیکونو په اړه وغږیږو، کله چې تاسو په خپل ماشین کې 32، 64، 128، 256 GB حافظه لرئ، نو معمول لوی پاڼې سم دي، او موږ په ساده ډول شفاف غیر فعال کوو.
او د حافظې په اړه وروستی شی مستقیم د میوو سره تړاو نلري، دا واقعیا ستاسو ژوند خرابولی شي. ټول ټریپټ به د دې حقیقت لخوا خورا اغیزمن شي چې سرور په دوامداره توګه بدلیږي.
او دا به په یو شمیر لارو کې خورا ناخوښه وي. او اصلي ستونزه دا ده چې عصري دانا د پخوانیو لینکس کرنلونو څخه یو څه توپیر لري. او دا کار د ګام پورته کولو لپاره خورا ناخوښه دی، ځکه کله چې موږ د تبادلې سره د یو ډول کار په اړه خبرې کوو، دا د OOM-وژونکي په ناڅاپي راتګ سره پای ته رسیږي. او د OOM وژونکی ، کوم چې په خپل وخت نه و رسیدلی او PostgreSQL یې غورځولی ، ناخوښه دی. هرڅوک به د دې په اړه پوه شي، دا دی، تر وروستي کاروونکي پورې.
څه خبرې دي؟ تاسو هلته د رام لوی مقدار لرئ، هرڅه ښه کار کوي. مګر د ځینو دلیلونو لپاره سرور په سویپ کې ځړیږي او د دې له امله ورو کیږي. داسې ښکاري چې ډیر حافظه شتون لري، مګر دا پیښیږي.
مخکې، موږ مشوره ورکړه چې vm.swappiness صفر ته تنظیم کړئ، د بیلګې په توګه د سویپ غیر فعال کول. مخکې، داسې بریښي چې د 32 GB RAM او ورته شریک بفرونه خورا لوی مقدار و. د تبادلې اصلي موخه دا ده چې د کرسټ د غورځولو لپاره یو ځای ولرئ که چیرې موږ سقوط وکړو. او دا نور په ځانګړي ډول نه و پوره شوی. او بیا د دې کرست سره څه کوئ؟ دا یو کار دی چیرې چې دا خورا روښانه نده چې ولې سویپ ته اړتیا ده ، په ځانګړي توګه د داسې اندازې.
مګر په ډیر عصري کې، د بیلګې په توګه، د کرنل دریم نسخه، چلند بدل شوی. او که تاسو سویپ صفر ته وټاکئ ، یعنی دا بند کړئ ، نو ژر یا وروسته ، حتی که یو څه رام پاتې وي ، د OOM قاتل به تاسو ته راشي ترڅو خورا شدید مصرف کونکي ووژني. ځکه چې هغه به په پام کې ونیسي چې د داسې کاري بار سره موږ لاهم لږ څه پاتې یو او موږ به کودتا وکړو، د بیلګې په توګه، د سیسټم پروسې د ناکامولو لپاره نه، مګر یو څه لږ مهم دی. دا لږ مهم به د ګډې حافظې ژور مصرف کونکی وي ، یعنی پوسټ ماسټر. او له هغې وروسته به ښه وي که اډه بیا رغول نه وي.
له همدې امله، اوس ډیفالټ، تر هغه ځایه چې زه په یاد لرم، ډیری توزیعونه د 6 په شاوخوا کې دي، د بیلګې په توګه تاسو باید په کوم ځای کې د سویپ کارول پیل کړئ پدې پورې اړه لري چې څومره حافظه پاتې ده. موږ اوس د vm.swappiness = 1 تنظیم کولو مشوره ورکوو، ځکه چې دا په عملي توګه دا بندوي، مګر د OOM-وژونکي په څیر ورته اغیزې نه ورکوي چې په ناڅاپي ډول راغلی او ټول شیان یې وژلي.
ورپسی څه دي؟ کله چې موږ د ډیټابیس فعالیت په اړه وغږیږو او په تدریجي ډول د ډیسکونو په لور حرکت کوو، هرڅوک د خپل سر په نیولو پیل کوي. ځکه حقیقت دا دی چې ډیسک سست دی او حافظه یې ګړندۍ ده هرڅوک له ماشومتوب څخه پیژني. او هرڅوک پوهیږي چې ډیټابیس به د ډیسک فعالیت ستونزې ولري.
اصلي PostgreSQL فعالیت ستونزه چې د پوستې سپیکونو سره تړاو لري نه پیښیږي ځکه چې ډیسک ورو دی. دا ډیری احتمال د دې حقیقت له امله دی چې حافظه او ډیسک بینډ ویت متوازن ندي. په هرصورت، دوی ممکن په مختلفو ځایونو کې متوازن نه وي. PostgreSQL نه دی ترتیب شوی، OS ترتیب شوی نه دی، هارډویر نه دی ترتیب شوی او هارډویر غلط دی. او دا ستونزه یوازې هغه وخت نه پیښیږي کله چې هرڅه پیښیږي لکه څنګه چې باید وي ، د بیلګې په توګه یا هیڅ بار شتون نلري ، یا تنظیمات او هارډویر ښه غوره شوي.
دا څه شی دی او څه ډول ښکاري؟ معمولا هغه خلک چې د PostgreSQL سره کار کوي له یو ځل څخه ډیر پدې مسله کې داخل شوي. زه به تشریح کړم. لکه څنګه چې ما وویل، PostgreSQL په وخت سره پوستې جوړوي ترڅو خندا پاڼې په ګډ حافظه کې ډیسک ته ډمپ کړي. که موږ په پراخه کچه شریکه حافظه ولرو، نو بیا پوسته په ډیسک باندې ژوره اغیزه پیل کوي، ځکه چې دا پاڼې د fsync سره ډمپ کوي. دا د کرنل بفر ته راځي او د fsync په کارولو سره ډیسکونو ته لیکل کیږي. او که د دې سوداګرۍ حجم لوی وي، نو موږ کولی شو یو ناخوښه اغیزه وګورو، د بیلګې په توګه د ډیسکونو خورا لوی کارول.
دلته زه دوه عکسونه لرم. زه به اوس تشریح کړم چې دا څه دي. دا دوه د وخت سره تړلي ګرافونه دي. لومړی ګراف د ډیسک کارول دي. دلته دا په دې وخت کې نږدې 90٪ ته رسیږي. که تاسو د فزیکي ډیسکونو سره د ډیټابیس ناکامي لرئ ، د RAID کنټرولر کارولو سره په 90٪ کې ، نو دا بد خبر دی. دا پدې مانا ده چې یو څه نور او دا به 100 ته ورسیږي او I/O به ودریږي.
که تاسو د ډیسک صف لرئ، نو دا یو څه مختلف کیسه ده. دا په دې پورې اړه لري چې دا څنګه تنظیم شوی، دا کوم ډول صف دی، او داسې نور.
او په موازي توګه، د داخلي پوسټګریس لید څخه ګراف دلته ترتیب شوی، کوم چې د پوستې پوسته څنګه واقع کیږي. او دلته شنه رنګ ښیي چې څومره بفرونه، دا خندا پاڼې، په دې وخت کې د همغږۍ لپاره دې پوستې ته رسیدلي. او دا اصلي شی دی چې تاسو باید دلته پوه شئ. موږ ګورو چې موږ دلته ډیری پاڼې لرو او په ځینو وختونو کې موږ تخته وهو، دا موږ لیکلي او لیکلي، دلته د ډیسک سیسټم په ښکاره ډول ډیر بوخت دی. او زموږ پوسته په ډیسک کې خورا قوي اغیزه لري. په عین حال کې، وضعیت باید داسې ښکاري، د بیلګې په توګه موږ دلته لږ ریکارډ درلود. او موږ کولی شو دا د تنظیماتو سره سم کړو نو دا به همداسې دوام وکړي. یعني، ریسایکل یې کوچنی دی، خو دلته یو څه لیکل کوو.
د دې ستونزې د له منځه وړلو لپاره څه باید وشي؟ که تاسو د ډیټابیس لاندې IO بند کړی وي، دا پدې مانا ده چې ټول هغه کاروونکي چې د دوی غوښتنې پوره کولو لپاره راغلي انتظار به وکړي.
که تاسو د لینکس له نظره ګورئ ، که تاسو ښه هارډویر اخیستی وي ، په سمه توګه یې تنظیم کړی وي ، په نورمال ډول د PostgreSQL تنظیم کړي ترڅو دا پوستې لږ ځله رامینځته کړي ، د یو بل ترمینځ د وخت په تیریدو سره خپروي ، نو تاسو د ډیفالټ ډیبیان پیرامیټرو ته ځئ. د ډیری لینکس توزیع لپاره، دا انځور دی: vm.dirty_ratio=20، vm.dirty_background_ratio=10.
دا څه معنی ورکوي؟ یو فلش شیطان د کرنل 2.6 څخه څرګند شو. Pdglush، په دې پورې اړه لري چې څوک د چا څخه کار اخلي، کوم چې د کرنل بفر څخه د ناپاکو پاڼو شالید ردولو کې بوخت دی او کله چې د ناپاکو پاڼو پریښودلو ته اړتیا وي، پرته له دې چې هر څه وي، کله چې د شالید پاڼې پریښودل مرسته نه کوي.
پس منظر کله راځي؟ کله چې په سرور کې د موجود ټول RAM 10٪ د کرنل بفر کې د خندا پاڼو لخوا نیول کیږي، په شالید کې د لیکلو ځانګړي فعالیت ویل کیږي. ولې پس منظر دی؟ د پیرامیټر په توګه، دا په پام کې نیسي چې څومره پاڼې باید ولیکئ. او، راځئ چې ووایو، هغه د N پاڼې لیکي. او د یو څه وخت لپاره دا شی په خوب کې راځي. او بیا هغه بیا راځي او یو څه نور پاڼې کاپي کوي.
دا یوه ډیره ساده کیسه ده. دلته ستونزه د لامبو حوض په څیر ده، کله چې یو پایپ ته ننوځي، بل ته بهیږي. زموږ پوسته راورسیده او که چیرې دا د ردولو لپاره یو څو ناپاکې پاڼې واستول شي، نو په تدریجي ډول به ټول شی د کرنل بفر pgflush څخه په ښه توګه حل شي.
که دا ناپاکې پاڼې په دوامداره توګه راټولې شي، دوی تر 20٪ پورې راټولیږي، وروسته له دې چې د OS لومړیتوب دا دی چې ټول شیان ډیسک ته ولیکئ، ځکه چې بریښنا به ناکام شي او هرڅه به زموږ لپاره خراب وي. موږ به دا ډاټا له لاسه ورکړو، د بیلګې په توګه.
چال څه دی؟ چال دا دی چې دا پیرامیټرې په عصري نړۍ کې د ټول RAM 20 او 10٪ دي چې په ماشین کې دي، دوی د هر ډیسک سیسټم له لارې چې تاسو یې لرئ په بشپړ ډول شیطاني دي.
تصور وکړئ چې تاسو 128 GB رام لرئ. 12,8 GB ستاسو ډیسک سیسټم ته راځي. او مهمه نده چې تاسو هلته کومه زیرمه لرئ ، مهمه نده چې تاسو هلته کوم صف لرئ ، دوی به دومره اوږد نه وي.
له همدې امله، موږ وړاندیز کوو چې تاسو سمدلاسه دا شمیرې د خپل RAID کنټرولر وړتیاو پراساس تنظیم کړئ. ما سمدلاسه دلته د کنټرولر لپاره وړاندیز وکړ چې د 512 MB کیچ لري.
هرڅه خورا ساده ګڼل کیږي. تاسو کولی شئ vm.dirty_background په بایټ کې واچوئ. او دا ترتیبات مخکیني دوه لغوه کوي. یا هم نسبت د ډیفالټ له مخې وي، یا هغه چې بایټونه لري فعال شوي وي، بیا هغه کسان چې بایټ لري کار کوي. مګر له هغه ځایه چې زه د DBA مشاور یم او د مختلف پیرودونکو سره کار کوم ، زه هڅه کوم چې ډډونه رسم کړم او له همدې امله ، که په بایټ کې ، بیا په بایټ کې. هیچا هیڅ تضمین نه دی ورکړی چې یو ښه مدیر به سرور ته نور حافظه اضافه نکړي ، ریبوټ یې کړي ، او ارقام به ورته پاتې شي. یوازې دا شمیرې محاسبه کړئ ترڅو هرڅه د تضمین سره سم وي.
که تاسو مناسب نه یاست نو څه کیږي؟ ما لیکلي دي چې هر ډول فلش کول په مؤثره توګه ودرول کیږي، مګر په حقیقت کې دا د وینا بڼه ده. عملیاتي سیسټم یوه لویه ستونزه لري - دا ډیری ناپاکې پاڼې لري، نو هغه IO چې ستاسو مراجعین یې تولیدوي په مؤثره توګه ودرول شوي، د بیلګې په توګه، غوښتنلیک ډیټابیس ته د sql پوښتنې لیږلو لپاره راغلی، دا انتظار کوي. دې ته هر ډول داخل / محصول ترټولو ټیټ لومړیتوب دی ، ځکه چې ډیټابیس د یوې پوستې لخوا نیول شوی. او کله چې هغه به پای ته ورسوي دا په بشپړ ډول ناڅرګنده ده. او کله چې تاسو غیر پس منظر فلش کول ترلاسه کړل، دا پدې مانا ده چې ستاسو ټول IO د هغې لخوا نیول شوي. او تر هغه چې دا پای ته ورسیږي، تاسو به هیڅ نه کوئ.
دلته دوه نور مهم ټکي شتون لري چې د دې راپور له دائرې څخه بهر دي. دا تنظیمات باید په postgresql.conf کې د ترتیباتو سره سمون ولري، د بیلګې په توګه د پوستې ترتیبات. او ستاسو د ډیسک سیسټم باید په مناسب ډول تنظیم شي. که تاسو په RAID کې کیچ لرئ، نو دا باید بیټرۍ ولري. خلک د بیټرۍ پرته د ښه کیچ سره RAID اخلي. که تاسو په RAID کې SSDs لرئ، نو دوی باید سرور وي، هلته باید capacitors وي. دلته یو مفصل چک لیست دی. دا لینک زما راپور لري چې څنګه په PostgreSQL کې د فعالیت ډیسک تنظیم کړئ. دلته دا ټول چک لیستونه شتون لري.
بل څه کولی شي ژوند خورا ستونزمن کړي؟ دا دوه پیرامیټونه دي. دوی نسبتا نوي دي. په ډیفالټ ، دوی په مختلف غوښتنلیکونو کې شامل کیدی شي. او دوی کولی شي ژوند ورته ستونزمن کړي که چیرې دوی په غلط ډول چالان شوي وي.
دوه نسبتا نوي شیان شتون لري. دوی لا دمخه په دریم کور کې څرګند شوي. دا په nanoseconds او sched_autogroup_enabled کې sched_migration_cost دی، کوم چې د ډیفالټ له مخې یو دی.
او دوی څنګه ستاسو ژوند خرابوي؟ د مهاجرت_لګښت څه شی دی؟ په لینکس کې، مهالویش کونکی کولی شي یوه پروسه له یو CPU څخه بل ته انتقال کړي. او د PostgreSQL لپاره، کوم چې پوښتنې اجرا کوي، بل CPU ته مهاجرت په بشپړه توګه ناڅرګند دی. د عملیاتي سیسټم له نظره، کله چې تاسو د پرانیستې دفتر او ترمینل ترمنځ وینډوز بدل کړئ، دا ممکن ښه وي، مګر د ډیټابیس لپاره دا خورا خراب دی. له همدې امله، یو معقول پالیسي دا ده چې د مهاجرت_لګښت یو څه لوی ارزښت ته، لږترلږه څو زره نانوسیکنډونو ته وټاکئ.
دا به د مهالویش لپاره څه معنی ولري؟ دا به په پام کې ونیول شي چې په دې وخت کې دا پروسه لاهم ګرمه ده. دا دی، که تاسو اوږدمهاله معامله لرئ چې د اوږدې مودې لپاره یو څه ترسره کوئ، مهالویش به پدې پوه شي. هغه به ګومان وکړي چې تر هغه وخته پورې چې دا وخت تیریږي، د دې پروسې هیڅ ځای ته د مهاجرت اړتیا نشته. که چیرې په ورته وخت کې پروسه یو څه وکړي، نو دا به چیرته نه لیږدول کیږي، دا به په خاموشۍ سره په CPU کې کار وکړي چې ورته ورته ځانګړې شوې وه. او پایله خورا ښه ده.
دوهم ټکی د اتومات ګروپ دی. د ځانګړو کاري بارونو لپاره یو ښه نظر شتون لري چې د عصري ډیټابیسونو سره تړاو نلري - دا د مجازی ټرمینل لخوا د ګروپ پروسو لپاره دی چې له کوم ځای څخه دوی پیل شوي. دا د ځینو کارونو لپاره مناسب دی. په عمل کې، PostgreSQL یو څو پروسس سیسټم دی چې د پریفورک سره چې د یو واحد ټرمینل څخه تیریږي. تاسو د تالاشۍ لیکونکی لرئ، پوسته لرئ، او ستاسو د پیرودونکي ټولې غوښتنې به په هر CPU کې په یو مهالویش کې ګروپ شي. او دوی به هلته په یووالي سره د هغه د آزاد کیدو لپاره انتظار باسي ، ترڅو د یو بل سره مداخله وکړي او هغه د اوږدې مودې لپاره اشغال کړي. دا یوه کیسه ده چې د داسې بار په حالت کې په بشپړ ډول غیر ضروري ده او له همدې امله باید بند شي.
زما همکار الیکسي لیسوفسکي د ساده پی جی بینچ سره ازموینې ترسره کړې ، چیرې چې هغه د مهاجرت_ لګښت د اندازې په ترتیب سره ډیر کړ او د اتومات ګروپ بند کړ. په خراب هارډویر کې توپیر نږدې 10٪ و. د پوسټګریس میلینګ لیست کې بحث شتون لري چیرې چې خلک د پوښتنې سرعت ته د ورته بدلونونو پایلې ورکوي 50٪ اغیزمن شوی. دا ډول کیسې ډیرې دي.
او په نهایت کې ، د بریښنا سپمولو پالیسۍ په اړه. ښه خبره دا ده چې لینکس اوس په لپ ټاپ کې کارول کیدی شي. او داسې انګیرل کیږي چې بیټرۍ به ښه وکاروي. مګر ناڅاپه دا معلومه شوه چې دا په سرور کې هم پیښ کیدی شي.
سربیره پردې ، که تاسو د ځینې کوربه څخه سرورونه کرایه کوئ ، نو "ښه" کوربه توب پروا نه کوي چې تاسو غوره فعالیت لرئ. د دوی دنده دا ده چې ډاډ ترلاسه کړي چې د دوی اوسپنې د امکان تر حده په مؤثره توګه کارول کیږي. له همدې امله، د ډیفالټ په واسطه دوی کولی شي په عملیاتي سیسټم کې د لپ ټاپ بریښنا سپمولو حالت فعال کړي.
که تاسو دا توکي په سرور کې د ډیر بار لاندې ډیټابیس سره کاروئ ، نو ستاسو انتخاب acpi_cpufreq + permormance دی. حتی د غوښتنې سره به ستونزې وي.
Intel_pstate یو څه مختلف چلوونکی دی. او اوس دې ته ترجیح ورکول کیږي، ځکه چې دا وروسته دی او ښه کار کوي.
او، په وینا، والي یوازې فعالیت دی. Ondemand، powersave او نور هرڅه ستاسو په اړه ندي.
د توضیحي تحلیل پایلې PostgreSQL کیدای شي د ډیری حکمونو له مخې توپیر ولري که تاسو د ځواک خوندي کول فعال کړئ، ځکه چې په عملي توګه ستاسو د ډیټابیس لاندې CPU به په بشپړ ډول غیر متوقع ډول پرمخ ځي.
دا توکي ممکن په ډیفالټ کې شامل شي. په احتیاط سره وګورئ چې وګورئ ایا دوی دا په ډیفالټ بدل کړی. دا واقعیا یوه لویه ستونزه کیدی شي.
او په پای کې، زه غواړم ووایم چې زموږ د PosgreSQL - مشورتي DBA ټیم څخه د هلکانو څخه مننه کوم، لکه میکس بوګوک او الیکسي لیسوفسکي، چې هره ورځ پدې مسله کې پرمختګ کوي. او موږ هڅه کوو چې د خپلو پیرودونکو لپاره ترټولو غوره کار وکړو ترڅو دا ټول د دوی لپاره کار وکړي. دا د هوایی چلند خوندیتوب لارښوونو سره ورته دی. دلته هر څه په وینو لیکل شوي. د دغو مغزاتو څخه هر یو د یو ډول ستونزو په بهیر کې موندل کیږي. زه خوښ یم چې دوی له تاسو سره شریک کړم.
پوښتنې:
له تاسو مننه! که ، د مثال په توګه ، یو شرکت غواړي پیسې خوندي کړي او ډیټابیس او غوښتنلیک منطق په یو سرور کې ځای په ځای کړي ، یا که شرکت د مایکرو سرویس معمارۍ فیشن رجحان تعقیب کړي ، په کوم کې چې PostgreSQL په کانټینر کې پرمخ ځي. چال څه دی؟ Sysctl به په ټوله نړۍ کې ټول دانا اغیزه وکړي. ما نه دي اوریدلي چې سیسټلونه په یو ډول مجازی شوي ترڅو دوی په کانټینر کې په جلا توګه کار وکړي. دلته یوازې cgroup شتون لري او هلته یوازې د کنټرول برخه ده. تاسو څنګه کولی شئ له دې سره ژوند وکړئ؟ یا که تاسو فعالیت غواړئ، نو بیا په جلا هارډویر سرور کې PostgreSQL چل کړئ او دا یې ټون کړئ؟
موږ ستاسو پوښتنې ته په دریو لارو ځواب ورکړو. که موږ د هارډویر سرور په اړه خبرې نه کوو چې ټون کیدی شي ، او داسې نور ، نو آرام اوسئ ، هرڅه به د دې تنظیماتو پرته سم کار وکړي. که تاسو دومره بار ولرئ چې تاسو د دې ترتیباتو جوړولو ته اړتیا لرئ، نو تاسو به د دې ترتیباتو څخه مخکې د اوسپنې سرور ته ورشئ.
څه مشکل ده؟ که دا یو مجازی ماشین وي، نو ډیری احتمال به تاسو ډیری ستونزې ولرئ، د بیلګې په توګه، د دې حقیقت سره چې په ډیری مجازی ماشینونو کې د ډیسک ځنډ خورا متضاد دی. حتی که د ډیسک ټروپوټ ښه وي، نو بیا د I/O لیږد ناکام شوی چې د پوستې په وخت کې یا WAL ته د لیکلو په وخت کې په اوسط ډول اغیزه نه کوي، نو ډیټابیس به له دې څخه ډیر زیانمن کړي. او تاسو به دا خبر کړئ مخکې لدې چې تاسو دې ستونزو ته ورسیږئ.
که تاسو په ورته سرور کې NGINX لرئ، تاسو به هم ورته ستونزه ولرئ. هغه به د ګډې حافظې لپاره مبارزه وکړي. او تاسو به دلته تشریح شوي ستونزو ته ورسیږئ.
مګر له بلې خوا، ځینې دا پیرامیټونه به لاهم ستاسو لپاره اړوند وي. د مثال په توګه، د sysctl سره dirty_ratio تنظیم کړئ ترڅو دا دومره لیونی نه وي - په هر حالت کې، دا به مرسته وکړي. یوه لاره یا بل، تاسو به د ډیسک سره متقابل عمل ولرئ. او دا به د غلط نمونې مطابق وي. دا عموما د پیرامیټونو لپاره ډیفالټ دی چې ما ښودلی. او په هر حالت کې دا غوره ده چې دوی بدل کړئ.
مګر ممکن د NUMA سره ستونزې وي. VmWare، د بیلګې په توګه، د NUMA سره په سمه توګه د مخالف ترتیباتو سره ښه کار کوي. او دلته تاسو باید غوره کړئ - د اوسپنې سرور یا غیر اوسپنې.
زه د ایمیزون AWS پورې اړوند یوه پوښتنه لرم. دوی مخکې له مخکې ترتیب شوي انځورونه لري. یو له دوی څخه د ایمیزون RDS په نوم یادیږي. ایا د دوی عملیاتي سیسټم لپاره کوم دودیز ترتیبات شتون لري؟
هلته ترتیبات شتون لري، مګر دوی مختلف ترتیبات دي. دلته موږ عملیاتي سیسټم په دې شرایطو کې تنظیم کوو چې ډیټابیس به دا شی څنګه وکاروي. او داسې پیرامیټونه شتون لري چې دا ټاکي چې موږ باید اوس چیرته ځو، لکه شکل ورکول. دا چې موږ ډیرو سرچینو ته اړتیا لرو، اوس به یې وخورو. له دې وروسته، ایمیزون RDS دا سرچینې سختوي، او فعالیت هلته راټیټیږي. دلته انفرادي کیسې شتون لري چې څنګه خلک د دې مسلې سره ګډوډي پیل کوي. ځینې وختونه حتی په بریالیتوب سره. مګر دا د OS تنظیماتو سره هیڅ تړاو نلري. دا د بادل هیک کولو په څیر دی. دا یوه بله کیسه ده.
ولې شفافې لویې پاڼې د لوی TLB په پرتله هیڅ اغیزه نلري؟
مه ورکوه. دا په ډیری لارو تشریح کیدی شي. مګر په حقیقت کې دوی په ساده ډول دا نه ورکوي. د PostgreSQL تاریخ څه دی؟ په پیل کې، دا د ګډې حافظې لویه برخه تخصیص کوي. ایا دوی شفاف دي یا نه په بشپړ ډول غیر اړونده دي. دا حقیقت چې دوی په پیل کې ولاړ دي هرڅه تشریح کوي. او که چیرې ډیر حافظه شتون ولري او تاسو اړتیا لرئ د شریک شوي_میموري برخې بیا رغونه وکړئ، نو شفافې لوی پاڼې به اړونده وي. په PostgreSQL کې، دا په ساده ډول په پیل کې په لویه برخه کې تخصیص شوی او دا دی، او بیا هلته هیڅ شی نه پیښیږي. تاسو کولی شئ، البته، دا وکاروئ، مګر د شریک شوي یادښت د فساد ترلاسه کولو چانس شتون لري کله چې دا یو څه بیا تخصیص کوي. PostgreSQL پدې اړه نه پوهیږي.
سرچینه: www.habr.com