ఇలియా కోస్మోడెమియన్స్కీచే 2015 నివేదిక యొక్క ట్రాన్స్క్రిప్ట్ "PostgreSQL పనితీరును మెరుగుపరచడానికి Linux ట్యూనింగ్"
నిరాకరణ: ఈ నివేదిక నవంబర్ 2015 నాటిదని నేను గమనించాను - 4 సంవత్సరాలకు పైగా గడిచిపోయింది మరియు చాలా సమయం గడిచిపోయింది. నివేదికలో చర్చించబడిన సంస్కరణ 9.4కు మద్దతు లేదు. గత 4 సంవత్సరాలలో, PostgreSQL యొక్క 5 కొత్త విడుదలలు విడుదల చేయబడ్డాయి మరియు Linux కెర్నల్ యొక్క 15 సంస్కరణలు విడుదల చేయబడ్డాయి. మీరు ఈ భాగాలను తిరిగి వ్రాస్తే, మీరు వేరే నివేదికతో ముగుస్తుంది. కానీ ఇక్కడ మేము PostgreSQL కోసం ప్రాథమిక Linux ట్యూనింగ్‌ను పరిశీలిస్తాము, ఇది నేటికీ సంబంధితంగా ఉంది.
నా పేరు ఇలియా కోస్మోడెమియన్స్కీ. నేను PostgreSQL-కన్సల్టింగ్‌లో పని చేస్తున్నాను. మరియు ఇప్పుడు నేను సాధారణంగా డేటాబేస్‌లకు సంబంధించి Linuxతో ఏమి చేయాలో మరియు ముఖ్యంగా PostgreSQL గురించి కొంచెం మాట్లాడతాను, ఎందుకంటే సూత్రాలు చాలా పోలి ఉంటాయి.
మనం దేని గురించి మాట్లాడుతాము? మీరు PostgreSQLతో కమ్యూనికేట్ చేస్తే, కొంత వరకు మీరు UNIX అడ్మిన్ అయి ఉండాలి. దాని అర్థం ఏమిటి? మేము Oracle మరియు PostgreSQLని పోల్చినట్లయితే, Oracleలో మీరు 80% DBA డేటాబేస్ అడ్మిన్ మరియు 20% Linux అడ్మిన్ అయి ఉండాలి.
PostgreSQL తో ఇది కొంచెం క్లిష్టంగా ఉంటుంది. PostgreSQLతో మీరు Linux ఎలా పనిచేస్తుందనే దానిపై మరింత మెరుగైన అవగాహన కలిగి ఉండాలి. మరియు అదే సమయంలో, లోకోమోటివ్ తర్వాత కొంచెం నడపండి, ఎందుకంటే ఇటీవల ప్రతిదీ చాలా చక్కగా నవీకరించబడింది. మరియు కొత్త కెర్నలు విడుదల చేయబడతాయి మరియు కొత్త కార్యాచరణ కనిపిస్తుంది, పనితీరు మెరుగుపడుతుంది, మొదలైనవి.
మేము Linux గురించి ఎందుకు మాట్లాడుతున్నాము? మేము Linux కాన్ఫరెన్స్ పీటర్‌లో ఉన్నందున అస్సలు కాదు, కానీ ఆధునిక పరిస్థితులలో సాధారణంగా డేటాబేస్‌లను ఉపయోగించడం కోసం అత్యంత సమర్థించబడిన ఆపరేటింగ్ సిస్టమ్‌లలో ఒకటి మరియు ముఖ్యంగా PostgreSQL Linux. ఎందుకంటే FreeBSD, దురదృష్టవశాత్తు, చాలా విచిత్రమైన దిశలో అభివృద్ధి చెందుతోంది. మరియు పనితీరుతో మరియు అనేక ఇతర విషయాలతో సమస్యలు ఉంటాయి. Windowsలో PostgreSQL యొక్క పనితీరు సాధారణంగా ఒక ప్రత్యేక తీవ్రమైన సమస్య, Windowsకు UNIX వలె భాగస్వామ్య మెమరీ లేదు, అయితే PostgreSQL అన్ని దీనితో ముడిపడి ఉంది, ఎందుకంటే ఇది బహుళ-ప్రాసెస్ సిస్టమ్.
మరియు ప్రతి ఒక్కరూ సోలారిస్ వంటి ఎక్సోటిక్స్ పట్ల తక్కువ ఆసక్తిని కలిగి ఉన్నారని నేను భావిస్తున్నాను, కాబట్టి వెళ్దాం.
ఆధునిక Linux పంపిణీలో 1 కంటే ఎక్కువ syctl ఎంపికలు ఉన్నాయి, మీరు కెర్నల్‌ను ఎలా నిర్మిస్తారనే దానిపై ఆధారపడి ఉంటుంది. అదే సమయంలో, మేము వేర్వేరు గింజలను పరిశీలిస్తే, మనం అనేక మార్గాల్లో సర్దుబాటు చేయవచ్చు. వాటిని ఎలా మౌంట్ చేయాలో ఫైల్ సిస్టమ్ పారామితులు ఉన్నాయి. దీన్ని ఎలా ప్రారంభించాలనే దాని గురించి మీకు ప్రశ్నలు ఉంటే: BIOSలో ఏమి ప్రారంభించాలి, హార్డ్‌వేర్‌ను ఎలా కాన్ఫిగర్ చేయాలి మొదలైనవి.
ఇది చాలా రోజుల పాటు చర్చించబడే చాలా పెద్ద వాల్యూమ్, మరియు ఒక చిన్న నివేదికలో కాదు, కానీ ఇప్పుడు నేను ముఖ్యమైన విషయాలపై దృష్టి పెడతాను, మీరు Linuxలో మీ డేటాబేస్‌ను బాగా ఉపయోగించకుండా నిరోధించే హామీనిచ్చే రేక్‌లను ఎలా నివారించాలి వాటిని సరిదిద్దవద్దు. మరియు అదే సమయంలో, ఒక ముఖ్యమైన విషయం ఏమిటంటే, డేటాబేస్కు సరైన సెట్టింగులలో అనేక డిఫాల్ట్ పారామితులు చేర్చబడలేదు. అంటే, డిఫాల్ట్‌గా ఇది పేలవంగా పని చేస్తుంది లేదా అస్సలు పని చేయదు.
Linuxలో ఏ సంప్రదాయ ట్యూనింగ్ లక్ష్యాలు ఉన్నాయి? మీరందరూ Linux అడ్మినిస్ట్రేషన్‌తో వ్యవహరిస్తున్నందున, లక్ష్యాలు ఏమిటో ప్రత్యేకంగా వివరించాల్సిన అవసరం లేదని నేను భావిస్తున్నాను.
మీరు ట్యూన్ చేయవచ్చు:
- CPU
- మెమరీ.
- నిల్వ.
- ఇతర. మేము చిరుతిండి కోసం చివరిలో దీని గురించి మాట్లాడుతాము. కూడా, ఉదాహరణకు, శక్తి పొదుపు విధానం వంటి పారామితులు పనితీరును చాలా అనూహ్యమైన రీతిలో ప్రభావితం చేయగలవు మరియు అత్యంత ఆహ్లాదకరంగా ఉండవు.
PostgreSQL మరియు సాధారణంగా డేటాబేస్ యొక్క ప్రత్యేకతలు ఏమిటి? సమస్య ఏమిటంటే, మీరు ఏదైనా వ్యక్తిగత గింజను సర్దుబాటు చేయలేరు మరియు మా పనితీరు గణనీయంగా మెరుగుపడిందని చూడలేరు.
అవును, అటువంటి గాడ్జెట్లు ఉన్నాయి, కానీ డేటాబేస్ అనేది సంక్లిష్టమైన విషయం. ఇది సర్వర్ కలిగి ఉన్న అన్ని వనరులతో పరస్పర చర్య చేస్తుంది మరియు పూర్తి స్థాయిలో పరస్పర చర్య చేయడానికి ఇష్టపడుతుంది. మీరు హోస్ట్ OSని ఎలా ఉపయోగించాలో ఒరాకిల్ యొక్క ప్రస్తుత సిఫార్సులను పరిశీలిస్తే, ఇది ఆ మంగోలియన్ కాస్మోనాట్ గురించి జోక్ లాగా ఉంటుంది - కుక్కకు ఆహారం ఇవ్వండి మరియు దేనినీ తాకవద్దు. డేటాబేస్కు అన్ని వనరులను ఇద్దాం, డేటాబేస్ ప్రతిదీ క్రమబద్ధీకరిస్తుంది.
సూత్రప్రాయంగా, కొంత వరకు పరిస్థితి PostgreSQLతో సమానంగా ఉంటుంది. వ్యత్యాసం ఏమిటంటే, డేటాబేస్ ఇంకా అన్ని వనరులను తీసుకోలేకపోయింది, అంటే Linux స్థాయిలో ఎక్కడో మీరు అన్నింటినీ మీరే క్రమబద్ధీకరించుకోవాలి.
ప్రధాన ఆలోచన ఏమిటంటే, ఒకే లక్ష్యాన్ని ఎంచుకుని దాన్ని ట్యూన్ చేయడం ప్రారంభించడం కాదు, ఉదాహరణకు, మెమరీ, CPU లేదా అలాంటిదే, కానీ పనిభారాన్ని విశ్లేషించి, మంచి ప్రోగ్రామర్లు సృష్టించిన లోడ్‌ను సాధ్యమైనంతవరకు మెరుగుపరచడానికి ప్రయత్నించండి. మా వినియోగదారులతో సహా మా కోసం.
అది ఏమిటో వివరించడానికి ఇక్కడ ఒక చిత్రం ఉంది. Linux OS బఫర్ ఉంది మరియు షేర్డ్ మెమరీ ఉంది మరియు PostgreSQL షేర్డ్ బఫర్‌లు ఉన్నాయి. PostgreSQL, ఒరాకిల్ వలె కాకుండా, నేరుగా కెర్నల్ బఫర్ ద్వారా మాత్రమే పని చేస్తుంది, అనగా, డిస్క్ నుండి ఒక పేజీ దాని షేర్డ్ మెమొరీలోకి రావాలంటే, అది కెర్నల్ బఫర్ మరియు వెనుకకు వెళ్ళాలి, అదే పరిస్థితి.
డిస్క్‌లు ఈ సిస్టమ్‌లో నివసిస్తాయి. నేను దీన్ని డిస్క్‌లుగా గీసాను. వాస్తవానికి, RAID కంట్రోలర్ మొదలైనవి ఉండవచ్చు.
మరియు ఈ ఇన్‌పుట్-అవుట్‌పుట్ ఒక మార్గం లేదా మరొకటి ఈ విషయం ద్వారా జరుగుతుంది.
PostgreSQL ఒక క్లాసిక్ డేటాబేస్. లోపల ఒక పేజీ ఉంది. మరియు అన్ని ఇన్‌పుట్ మరియు అవుట్‌పుట్ పేజీలను ఉపయోగించి జరుగుతాయి. మేము బ్లాకులను పేజీలతో మెమరీలోకి పెంచుతున్నాము. మరియు ఏమీ జరగకపోతే, మేము వాటిని చదువుతాము, అప్పుడు క్రమంగా అవి ఈ కాష్ నుండి, భాగస్వామ్య బఫర్‌ల నుండి అదృశ్యమవుతాయి మరియు డిస్క్‌లో ముగుస్తాయి.
మనం ఎక్కడైనా ఏదైనా భర్తీ చేస్తే, మొత్తం పేజీ మురికిగా గుర్తించబడుతుంది. నేను వాటిని ఇక్కడ నీలం రంగులో గుర్తించాను. మరియు ఈ పేజీ తప్పనిసరిగా బ్లాక్ నిల్వతో సమకాలీకరించబడాలని దీని అర్థం. అంటే, మేము దానిని మురికిగా చేసినప్పుడు, మేము WALలో ఎంట్రీ ఇచ్చాము. మరియు కొన్ని అద్భుతమైన సమయంలో, చెక్‌పాయింట్ అని పిలువబడే ఒక దృగ్విషయం వచ్చింది. మరియు అతను వచ్చినట్లు ఈ లాగ్‌లో సమాచారం నమోదు చేయబడింది. మరియు ఈ భాగస్వామ్య బఫర్‌లలో ఆ సమయంలో ఇక్కడ ఉన్న అన్ని మురికి పేజీలు కెర్నల్ బఫర్ ద్వారా fsync ఉపయోగించి నిల్వ డిస్క్‌తో సమకాలీకరించబడ్డాయి.
ఇలా ఎందుకు చేస్తున్నారు? మేము వోల్టేజ్‌ను కోల్పోయినట్లయితే, మొత్తం డేటా పోయిన పరిస్థితిని మేము పొందలేము. ప్రతి ఒక్కరూ మాకు చెప్పిన శాశ్వత జ్ఞాపకశక్తి ఇప్పటివరకు డేటాబేస్ సిద్ధాంతంలో ఉంది - ఇది ఉజ్వలమైన భవిష్యత్తు, ఇది మేము ఖచ్చితంగా ప్రయత్నిస్తాము మరియు ఇష్టపడతాము, కానీ ప్రస్తుతానికి వారు మైనస్ 20 సంవత్సరాలలో జీవిస్తున్నారు. మరియు, వాస్తవానికి, ఇవన్నీ పర్యవేక్షించాల్సిన అవసరం ఉంది.
మరియు నిర్గమాంశను పెంచే పని ఏమిటంటే, ఈ దశలన్నింటిలో చక్కగా ట్యూన్ చేయడం, తద్వారా ఇవన్నీ త్వరగా ముందుకు వెనుకకు కదులుతాయి. షేర్డ్ మెమరీ ప్రాథమికంగా పేజీ కాష్. PostgreSQLలో మేము ఎంచుకున్న ప్రశ్న లేదా ఏదైనా పంపాము, అది డిస్క్ నుండి ఈ డేటాను తిరిగి పొందింది. అవి భాగస్వామ్య బఫర్‌లలో ముగిశాయి. దీని ప్రకారం, ఇది మెరుగ్గా పనిచేయాలంటే, చాలా మెమరీ ఉండాలి.
ఇవన్నీ బాగా మరియు త్వరగా పని చేయడానికి, మీరు అన్ని దశలలో ఆపరేటింగ్ సిస్టమ్‌ను సరిగ్గా కాన్ఫిగర్ చేయాలి. మరియు బ్యాలెన్స్‌డ్ హార్డ్‌వేర్‌ను ఎంచుకోండి, ఎందుకంటే మీకు ఏదో ఒక ప్రదేశంలో అసమతుల్యత ఉంటే, అప్పుడు మీరు చాలా మెమరీని చేయవచ్చు, కానీ అది తగినంత వేగంతో సేవ చేయబడదు.
మరియు ఈ పాయింట్లు ప్రతి ద్వారా వెళ్ళి తెలపండి.
ఈ పేజీలను ముందుకు వెనుకకు వేగంగా ప్రయాణించేలా చేయడానికి, మీరు ఈ క్రింది వాటిని సాధించాలి:
- మొదట, మీరు మెమరీతో మరింత సమర్థవంతంగా పని చేయాలి.
- రెండవది, మెమరీ నుండి పేజీలు డిస్క్‌కి వెళ్ళినప్పుడు ఈ పరివర్తన మరింత సమర్థవంతంగా ఉండాలి.
- మరియు మూడవది, మంచి డిస్కులు ఉండాలి.
మీరు సర్వర్‌లో 512 GB RAMని కలిగి ఉంటే మరియు అది ఎలాంటి కాష్ లేకుండా SATA హార్డ్ డ్రైవ్‌లో ముగుస్తుంది, అప్పుడు మొత్తం డేటాబేస్ సర్వర్ కేవలం గుమ్మడికాయగా కాకుండా SATA ఇంటర్‌ఫేస్‌తో గుమ్మడికాయగా మారుతుంది. మీరు నేరుగా దానిలోకి ప్రవేశిస్తారు. మరియు ఏదీ మిమ్మల్ని రక్షించదు.
జ్ఞాపకశక్తితో మొదటి పాయింట్‌కి సంబంధించి, జీవితాన్ని చాలా కష్టతరం చేసే మూడు అంశాలు ఉన్నాయి.
వాటిలో మొదటిది NUMA. NUMA అనేది పనితీరును మెరుగుపరచడానికి తయారు చేయబడిన విషయం. పనిభారాన్ని బట్టి, వివిధ విషయాలను ఆప్టిమైజ్ చేయవచ్చు. మరియు దాని కొత్త ప్రస్తుత రూపంలో, పేజీ కాష్ షేర్డ్ బఫర్‌లను తీవ్రంగా ఉపయోగించే డేటాబేస్ల వంటి అప్లికేషన్‌లకు ఇది చాలా మంచిది కాదు.
క్లుప్తంగా. NUMAలో ఏదైనా తప్పు ఉంటే మీరు ఎలా చెప్పగలరు? మీకు ఒక రకమైన అసహ్యకరమైన నాక్ ఉంది, అకస్మాత్తుగా కొంత CPU ఓవర్‌లోడ్ చేయబడింది. అదే సమయంలో, మీరు PostgreSQLలో ప్రశ్నలను విశ్లేషిస్తారు మరియు అక్కడ అలాంటిదేమీ లేదని చూడండి. ఈ ప్రశ్నలు చాలా CPU ఇంటెన్సివ్‌గా ఉండకూడదు. మీరు దీన్ని చాలా కాలం పాటు పట్టుకోవచ్చు. PostgreSQL కోసం NUMAని ఎలా కాన్ఫిగర్ చేయాలి అనేదానిపై మొదటి నుండి సరైన సిఫార్సును ఉపయోగించడం సులభం.
అసలు ఏం జరుగుతోంది? NUMA అంటే నాన్-యూనిఫాం మెమరీ యాక్సెస్. విషయం ఏంటి? మీకు CPU ఉంది, దాని పక్కన దాని స్థానిక మెమరీ ఉంది. మరియు ఈ మెమరీ ఇంటర్‌కనెక్ట్‌లు ఇతర CPUల నుండి మెమరీని పైకి లాగగలవు.
మీరు పరిగెత్తితే numactl --hardware, అప్పుడు మీరు ఇంత పెద్ద షీట్ పొందుతారు. ఇతర విషయాలతోపాటు, దూరాల ఫీల్డ్ ఉంటుంది. సంఖ్యలు ఉంటాయి - 10-20, అలాంటిదే. ఈ సంఖ్యలు ఈ రిమోట్ మెమరీని తీయడానికి మరియు స్థానికంగా ఉపయోగించడానికి హాప్‌ల సంఖ్య కంటే మరేమీ కాదు. సూత్రప్రాయంగా, మంచి ఆలోచన. ఇది పనిభారం పరిధిలో పనితీరును బాగా వేగవంతం చేస్తుంది.
ఇప్పుడు మీరు ఒక CPUని కలిగి ఉన్నారని ఊహించండి, మొదట దాని స్థానిక మెమరీని ఉపయోగించడానికి ప్రయత్నిస్తుంది, ఆపై ఏదో ఒకదాని కోసం ఇంటర్‌కనెక్ట్ ద్వారా మరొక మెమరీని పైకి లాగడానికి ప్రయత్నిస్తుంది. మరియు ఈ CPU మీ మొత్తం PostgreSQL పేజీ కాష్‌ని పొందుతుంది - అంతే, కొన్ని గిగాబైట్లు. మీరు ఎల్లప్పుడూ చెత్త కేసును పొందుతారు, ఎందుకంటే CPUలో సాధారణంగా ఆ మాడ్యూల్‌లోనే తక్కువ మెమరీ ఉంటుంది. మరియు సర్వీస్ చేయబడిన మొత్తం మెమరీ ఈ ఇంటర్‌కనెక్ట్‌ల ద్వారా వెళుతుంది. ఇది నెమ్మదిగా మరియు విచారంగా మారుతుంది. మరియు ఈ నోడ్ సేవలను అందించే మీ ప్రాసెసర్ నిరంతరం ఓవర్‌లోడ్ అవుతుంది. మరియు ఈ మెమరీ యాక్సెస్ సమయం చెడ్డది, నెమ్మదిగా ఉంది. మీరు దీన్ని డేటాబేస్ కోసం ఉపయోగిస్తుంటే మీరు కోరుకోని పరిస్థితి ఇది.
అందువల్ల, Linux ఆపరేటింగ్ సిస్టమ్‌కు అక్కడ ఏమి జరుగుతుందో తెలియకపోవడం డేటాబేస్ కోసం మరింత సరైన ఎంపిక. తద్వారా ఇది మెమరీని యాక్సెస్ చేస్తుంది.
అది ఎందుకు? ఇది మరో విధంగా ఉండాలి అని అనిపిస్తుంది. ఇది ఒక సాధారణ కారణం కోసం జరుగుతుంది: పేజీ కాష్ కోసం మనకు చాలా మెమరీ అవసరం - పదుల, వందల గిగాబైట్లు.
మరియు మేము ఇవన్నీ కేటాయించి, అక్కడ మా డేటాను కాష్ చేస్తే, మెమరీకి అటువంటి గమ్మత్తైన యాక్సెస్ నుండి వచ్చే లాభం కంటే కాష్‌ని ఉపయోగించడం వల్ల వచ్చే లాభం గణనీయంగా ఎక్కువగా ఉంటుంది. మరియు మేము NUMAని ఉపయోగించి మెమరీని మరింత సమర్ధవంతంగా యాక్సెస్ చేయగలము అనే వాస్తవంతో పోలిస్తే మేము సాటిలేని ప్రయోజనం పొందుతాము.
అందువల్ల, ఉజ్వలమైన భవిష్యత్తు వచ్చే వరకు, ప్రస్తుతానికి ఇక్కడ రెండు విధానాలు ఉన్నాయి మరియు డేటాబేస్ ఏ CPUలలో రన్ అవుతుందో మరియు ఎక్కడ నుండి ఏదైనా లాగాలి అని గుర్తించలేకపోతుంది.
కాబట్టి, NUMAని పూర్తిగా నిలిపివేయడమే సరైన విధానం, ఉదాహరణకు, రీబూట్ చేస్తున్నప్పుడు. చాలా సందర్భాలలో, గెలుపోటములు అటువంటి పరిమాణంలో ఉంటాయి, ఏది మంచిది అనే ప్రశ్న అస్సలు తలెత్తదు.
మరొక ఎంపిక ఉంది. మేము దీన్ని మొదటిదాని కంటే ఎక్కువగా ఉపయోగిస్తాము, ఎందుకంటే క్లయింట్ మద్దతు కోసం మా వద్దకు వచ్చినప్పుడు, సర్వర్‌ను రీబూట్ చేయడం అతనికి పెద్ద విషయం. అతనికి అక్కడ వ్యాపారం ఉంది. మరియు వారు NUMA కారణంగా సమస్యలను ఎదుర్కొంటారు. అందువల్ల, మేము రీబూట్ కంటే తక్కువ ఇన్వాసివ్ మార్గాల్లో దీన్ని డిసేబుల్ చేయడానికి ప్రయత్నిస్తాము, అయితే ఇది నిలిపివేయబడిందో లేదో తనిఖీ చేయడానికి జాగ్రత్తగా ఉండండి. ఎందుకంటే, అనుభవం చూపినట్లుగా, మేము పేరెంట్ PostgreSQL ప్రాసెస్‌లో NUMAని నిలిపివేయడం మంచిది, కానీ అది పని చేయడం అస్సలు అవసరం లేదు. ఆమె నిజంగా స్విచ్ ఆఫ్ చేసిందో లేదో తనిఖీ చేసి చూడాలి.
రాబర్ట్ హాస్ ద్వారా మంచి పోస్ట్ ఉంది. ఇది PostgreSQL కమిటర్లలో ఒకటి. అన్ని తక్కువ-స్థాయి గిబ్లెట్‌ల యొక్క ముఖ్య డెవలపర్‌లలో ఒకరు. మరియు మీరు ఈ పోస్ట్ నుండి లింక్‌లను అనుసరిస్తే, వారు NUMA వ్యక్తులకు జీవితాన్ని ఎలా కష్టతరం చేసిందనే దాని గురించి అనేక రంగుల కథలను వివరిస్తారు. చూడండి, మా డేటాబేస్ బాగా పని చేయడానికి సర్వర్‌లో కాన్ఫిగర్ చేయాల్సిన సిస్టమ్ అడ్మినిస్ట్రేటర్ చెక్‌లిస్ట్‌ను అధ్యయనం చేయండి. ఈ సెట్టింగులను వ్రాసి తనిఖీ చేయాలి, లేకుంటే అది చాలా మంచిది కాదు.
నేను మాట్లాడే అన్ని సెట్టింగ్‌లకు ఇది వర్తిస్తుందని దయచేసి గమనించండి. కానీ సాధారణంగా డేటాబేస్లు తప్పు సహనం కోసం మాస్టర్-స్లేవ్ మోడ్‌లో సేకరించబడతాయి. స్లేవ్‌లో ఈ సెట్టింగ్‌లు చేయడం మర్చిపోవద్దు ఎందుకంటే ఒక రోజు మీకు ప్రమాదం జరుగుతుంది మరియు మీరు బానిసకు మారతారు మరియు అది యజమాని అవుతుంది.
అత్యవసర పరిస్థితుల్లో, ప్రతిదీ చాలా చెడ్డగా ఉన్నప్పుడు, మీ ఫోన్ నిరంతరం రింగ్ అవుతూ ఉంటుంది మరియు మీ బాస్ పెద్ద కర్రతో పరుగెత్తుకుంటూ వస్తున్నప్పుడు, మీకు తనిఖీ చేయడం గురించి ఆలోచించే సమయం ఉండదు. మరియు ఫలితాలు చాలా వినాశకరమైనవి కావచ్చు.
తదుపరి పాయింట్ భారీ పేజీలు. భారీ పేజీలను విడిగా పరీక్షించడం కష్టం, మరియు దీన్ని చేయగల బెంచ్‌మార్క్‌లు ఉన్నప్పటికీ, అలా చేయడంలో అర్థం లేదు. అవి Googleకి సులువుగా ఉంటాయి.
విషయం ఏంటి? మీకు చాలా RAM ఉన్న చాలా ఖరీదైన సర్వర్ లేదు, ఉదాహరణకు, 30 GB కంటే ఎక్కువ. మీరు భారీ పేజీలను ఉపయోగించరు. మెమరీ వినియోగం పరంగా మీకు ఖచ్చితంగా ఓవర్ హెడ్ ఉందని దీని అర్థం. మరియు ఈ ఓవర్ హెడ్ చాలా ఆహ్లాదకరమైనది కాదు.
అది ఎందుకు? అయితే ఏమి జరుగుతుంది? ఆపరేటింగ్ సిస్టమ్ మెమరీని చిన్న ముక్కలుగా కేటాయిస్తుంది. ఇది చాలా సౌకర్యవంతంగా ఉంటుంది, ఇది చారిత్రాత్మకంగా ఎలా జరిగింది. మరియు మేము వివరాల్లోకి వెళితే, OS తప్పనిసరిగా వర్చువల్ చిరునామాలను భౌతిక వాటికి అనువదించాలి. మరియు ఈ ప్రక్రియ సరళమైనది కాదు, కాబట్టి OS ఈ ఆపరేషన్ ఫలితాన్ని అనువాద లుక్‌సైడ్ బఫర్ (TLB)లో క్యాష్ చేస్తుంది.
మరియు TLB కాష్ అయినందున, కాష్‌లో అంతర్గతంగా ఉన్న అన్ని సమస్యలు ఈ పరిస్థితిలో తలెత్తుతాయి. ముందుగా, మీరు చాలా RAM కలిగి ఉంటే మరియు అది చిన్న భాగాలుగా కేటాయించబడితే, ఈ బఫర్ చాలా పెద్దదిగా మారుతుంది. మరియు కాష్ పెద్దగా ఉంటే, దాని ద్వారా శోధించడం నెమ్మదిగా ఉంటుంది. ఓవర్‌హెడ్ ఆరోగ్యంగా ఉంది మరియు అది దానంతట అదే స్థలాన్ని తీసుకుంటుంది, అంటే RAM ఏదో తప్పుగా వినియోగించబడుతోంది. ఈసారి.
రెండు - అటువంటి పరిస్థితిలో కాష్ ఎంత ఎక్కువగా పెరుగుతుందో, మీకు కాష్ మిస్ అయ్యే అవకాశం ఎక్కువగా ఉంటుంది. మరియు ఈ కాష్ యొక్క సామర్థ్యం దాని పరిమాణం పెరిగేకొద్దీ వేగంగా తగ్గుతుంది. అందువలన, ఆపరేటింగ్ సిస్టమ్స్ ఒక సాధారణ విధానంతో ముందుకు వచ్చాయి. ఇది చాలా కాలంగా లైనక్స్‌లో ఉపయోగించబడుతోంది. ఇది చాలా కాలం క్రితం FreeBSDలో కనిపించింది. కానీ మేము Linux గురించి మాట్లాడుతున్నాము. ఇవి భారీ పేజీలు.
మరియు ఇక్కడ గమనించదగ్గ విషయం ఏమిటంటే, ఒక ఆలోచనగా, ఒరాకిల్ మరియు IBMలను కలిగి ఉన్న సంఘాల ద్వారా మొదట భారీ పేజీలు ముందుకు వచ్చాయి, అనగా డేటాబేస్ తయారీదారులు ఇది డేటాబేస్‌లకు కూడా ఉపయోగపడుతుందని గట్టిగా భావించారు.
మరియు దీన్ని PostgreSQLతో ఎలా స్నేహం చేయవచ్చు? ముందుగా, Linux కెర్నల్‌లో భారీ పేజీలు తప్పనిసరిగా ప్రారంభించబడాలి.
రెండవది, అవి sysctl పరామితి ద్వారా స్పష్టంగా పేర్కొనబడాలి - ఎన్ని ఉన్నాయి. ఇక్కడ ఉన్న నంబర్లు కొన్ని పాత సర్వర్ నుండి వచ్చినవి. మీరు ఎన్ని భాగస్వామ్య బఫర్‌లను కలిగి ఉన్నారో మీరు లెక్కించవచ్చు, తద్వారా భారీ పేజీలు అక్కడ సరిపోతాయి.
మరియు మీ సర్వర్ మొత్తం PostgreSQLకి అంకితం చేయబడితే, మీ డేటాబేస్ ఖచ్చితంగా ఈ 25%కి సరిపోతుందని మీకు ఖచ్చితంగా తెలిస్తే RAMలో 75% లేదా షేర్డ్ బఫర్‌లకు 75% కేటాయించడం మంచి ప్రారంభ స్థానం. ప్రారంభ స్థానం ఒకటి. మరియు పరిగణించండి, మీకు 256 GB RAM ఉంటే, తదనుగుణంగా, మీరు 64 GB పెద్ద బఫర్‌లను కలిగి ఉంటారు. కొంత మార్జిన్‌తో సుమారుగా లెక్కించండి - ఈ సంఖ్య దేనికి సెట్ చేయబడాలి.
వెర్షన్ 9.2కి ముందు (నేను పొరపాటుగా భావించకపోతే, వెర్షన్ 8.2 నుండి), మూడవ పక్షం లైబ్రరీని ఉపయోగించి PostgreSQLని భారీ పేజీలతో కనెక్ట్ చేయడం సాధ్యమైంది. మరియు ఇది ఎల్లప్పుడూ చేయాలి. ముందుగా, భారీ పేజీలను సరిగ్గా కేటాయించడానికి మీకు కెర్నల్ అవసరం. మరియు, రెండవది, తద్వారా వారితో పనిచేసే అప్లికేషన్ వాటిని ఉపయోగించవచ్చు. ఇది కేవలం ఆ విధంగా ఉపయోగించబడదు. PostgreSQL సిస్టమ్ 5 శైలిలో మెమరీని కేటాయించినందున, ఇది libhugetlbfsని ఉపయోగించి చేయవచ్చు - ఇది లైబ్రరీ పూర్తి పేరు.
9.3లో, మెమరీతో పని చేస్తున్నప్పుడు PostgreSQL పనితీరు మెరుగుపరచబడింది మరియు సిస్టమ్ 5 మెమరీ కేటాయింపు పద్ధతిని వదిలివేయబడింది. అందరూ చాలా సంతోషించారు, లేకుంటే మీరు ఒక మెషీన్‌లో రెండు PostgreSQL ఇన్‌స్టాన్స్‌లను అమలు చేయడానికి ప్రయత్నిస్తారు మరియు నా దగ్గర తగినంత షేర్డ్ మెమరీ లేదని అతను చెప్పాడు. మరియు అతను sysctl సరిదిద్దాలి అని చెప్పాడు. మరియు మీరు ఇప్పటికీ రీబూట్ చేయవలసిన అటువంటి sysctl ఉంది, మొదలైనవి సాధారణంగా, ప్రతి ఒక్కరూ సంతోషంగా ఉన్నారు. కానీ mmap మెమరీ కేటాయింపు భారీ పేజీల వినియోగాన్ని విచ్ఛిన్నం చేసింది. మా క్లయింట్‌లలో చాలామంది పెద్ద షేర్డ్ బఫర్‌లను ఉపయోగిస్తున్నారు. మరియు 9.3కి మారకూడదని మేము గట్టిగా సిఫార్సు చేసాము, ఎందుకంటే అక్కడ ఓవర్‌హెడ్ మంచి శాతాలలో లెక్కించడం ప్రారంభమైంది.
కానీ సంఘం ఈ సమస్యపై శ్రద్ధ చూపింది మరియు 9.4లో వారు ఈ ఈవెంట్‌ను చాలా చక్కగా పునర్నిర్మించారు. మరియు 9.4లో postgresql.confలో ఒక పరామితి కనిపించింది, దీనిలో మీరు ప్రయత్నించడాన్ని ఆన్ లేదా ఆఫ్ చేయవచ్చు.
ప్రయత్నించండి అనేది సురక్షితమైన ఎంపిక. PostgreSQL ప్రారంభించినప్పుడు, అది భాగస్వామ్య మెమరీని కేటాయించినప్పుడు, అది భారీ పేజీల నుండి ఈ మెమరీని పట్టుకోవడానికి ప్రయత్నిస్తుంది. మరియు అది పని చేయకపోతే, అది సాధారణ ఎంపికకు తిరిగి వస్తుంది. మరియు మీకు FreeBSD లేదా Solaris ఉంటే, మీరు ప్రయత్నించవచ్చు, ఇది ఎల్లప్పుడూ సురక్షితం.
ఆన్‌లో ఉంటే, భారీ పేజీల నుండి ఎంచుకోలేకపోతే అది ప్రారంభం కాదు. ఇక్కడ ఇది ఎవరు మరియు ఏది మంచిది అనే దాని గురించి ఇప్పటికే ఉంది. కానీ మీరు ప్రయత్నించినట్లయితే, మీరు నిజంగా హైలైట్ చేయాల్సిన వాటిని కలిగి ఉన్నారో లేదో తనిఖీ చేయండి, ఎందుకంటే లోపం కోసం చాలా స్థలం ఉంది. ప్రస్తుతం ఈ కార్యాచరణ Linuxలో మాత్రమే పని చేస్తుంది.
మేము మరింత ముందుకు వెళ్ళే ముందు మరో చిన్న గమనిక. పారదర్శక భారీ పేజీలు ఇంకా PostgreSQL గురించి లేవు. అతను వాటిని సాధారణంగా ఉపయోగించలేడు. మరియు అటువంటి పనిభారం కోసం పారదర్శక భారీ పేజీలతో, భాగస్వామ్య మెమరీ యొక్క పెద్ద భాగం అవసరమైనప్పుడు, ప్రయోజనాలు చాలా పెద్ద వాల్యూమ్‌లతో మాత్రమే వస్తాయి. మీకు టెరాబైట్‌ల మెమరీ ఉంటే, ఇది అమలులోకి రావచ్చు. మేము రోజువారీ అనువర్తనాల గురించి మాట్లాడుతున్నట్లయితే, మీ మెషీన్‌లో మీకు 32, 64, 128, 256 GB మెమరీ ఉన్నప్పుడు, అప్పుడు సాధారణ భారీ పేజీలు సరే, మరియు మేము పారదర్శకతను నిలిపివేస్తాము.
మరియు జ్ఞాపకశక్తికి సంబంధించిన చివరి విషయం ఫ్రూట్‌కు నేరుగా సంబంధించినది కాదు, ఇది నిజంగా మీ జీవితాన్ని నాశనం చేస్తుంది. సర్వర్ నిరంతరం ఇచ్చిపుచ్చుకోవడం వల్ల అన్ని నిర్గమాంశలు బాగా ప్రభావితమవుతాయి.
మరియు ఇది అనేక విధాలుగా చాలా అసహ్యకరమైనది. మరియు ప్రధాన సమస్య ఏమిటంటే ఆధునిక కెర్నలు పాత Linux కెర్నల్స్ నుండి కొద్దిగా భిన్నంగా ప్రవర్తిస్తాయి. మరియు ఈ విషయం అడుగు పెట్టడం చాలా అసహ్యకరమైనది, ఎందుకంటే మేము స్వాప్‌తో ఒక రకమైన పని గురించి మాట్లాడినప్పుడు, ఇది OOM- కిల్లర్ యొక్క అకాల రాకతో ముగుస్తుంది. మరియు OOM-కిల్లర్, ఇది సకాలంలో చేరుకోలేదు మరియు PostgreSQLని వదిలివేసింది, అసహ్యకరమైనది. దీని గురించి అందరికీ తెలుసు, అంటే చివరి వినియోగదారు వరకు.
ఏం జరుగుతోంది? మీకు అక్కడ పెద్ద మొత్తంలో RAM ఉంది, ప్రతిదీ బాగా పనిచేస్తుంది. కానీ కొన్ని కారణాల వల్ల సర్వర్ స్వాప్‌లో వేలాడుతోంది మరియు దీని కారణంగా నెమ్మదిస్తుంది. జ్ఞాపకశక్తి చాలా ఉన్నట్లు అనిపిస్తుంది, కానీ ఇది జరుగుతుంది.
మునుపు, మేము vm.swappinessని సున్నాకి సెట్ చేయమని సలహా ఇచ్చాము, అంటే స్వాప్‌ని నిలిపివేయండి. ఇంతకుముందు, 32 GB RAM మరియు సంబంధిత భాగస్వామ్య బఫర్‌లు భారీ మొత్తంలో ఉన్నట్లు అనిపించింది. స్వాప్ యొక్క ముఖ్య ఉద్దేశ్యం మనం పడిపోయినట్లయితే క్రస్ట్‌ను విసిరే స్థలాన్ని కలిగి ఉండటం. మరియు అది ఇకపై ప్రత్యేకంగా నెరవేరలేదు. ఆపై మీరు ఈ క్రస్ట్‌తో ఏమి చేయబోతున్నారు? ఇది స్వాప్ ఎందుకు అవసరమో స్పష్టంగా తెలియని పని, ప్రత్యేకించి అటువంటి పరిమాణం.
కానీ మరింత ఆధునికమైన, అంటే, కెర్నల్ యొక్క మూడవ సంస్కరణల్లో, ప్రవర్తన మార్చబడింది. మరియు మీరు స్వాప్‌ను సున్నాకి సెట్ చేస్తే, అంటే దాన్ని ఆఫ్ చేయండి, కొంత RAM మిగిలి ఉన్నప్పటికీ, ఒక OOM కిల్లర్ మీ వద్దకు వచ్చి అత్యంత తీవ్రమైన వినియోగదారులను చంపడానికి వస్తుంది. ఎందుకంటే అటువంటి పనిభారంతో మనకు ఇంకా కొంచెం మిగిలి ఉందని మరియు మేము బయటకు దూకుతాము, అంటే, సిస్టమ్ ప్రాసెస్‌ను నెయిల్ డౌన్ చేయడానికి కాదు, కానీ తక్కువ ప్రాముఖ్యత కలిగిన దానిని తగ్గించాలని అతను భావిస్తాడు. ఇది తక్కువ ప్రాముఖ్యత కలిగిన భాగస్వామ్య మెమరీ యొక్క ఇంటెన్సివ్ వినియోగదారుగా ఉంటుంది, అవి పోస్ట్‌మాస్టర్. మరియు ఆ తర్వాత బేస్ పునరుద్ధరించబడనట్లయితే అది మంచిది.
అందువల్ల, ఇప్పుడు డిఫాల్ట్, నాకు గుర్తున్నంత వరకు, చాలా పంపిణీలు ఎక్కడో 6 ఉన్నాయి, అంటే మీరు ఎంత మెమరీని వదిలిపెట్టిందో బట్టి మీరు ఏ సమయంలో స్వాప్‌ని ఉపయోగించడం ప్రారంభించాలి. మేము ఇప్పుడు vm.swappiness = 1ని సెట్ చేయమని సిఫార్సు చేస్తున్నాము, ఎందుకంటే ఇది ఆచరణాత్మకంగా దాన్ని ఆపివేస్తుంది, కానీ OOM-కిల్లర్‌తో ఊహించని విధంగా వచ్చి మొత్తం విషయాన్నే చంపేస్తుంది.
తరవాత ఏంటి? మేము డేటాబేస్ల పనితీరు గురించి మాట్లాడినప్పుడు మరియు క్రమంగా డిస్కుల వైపుకు వెళ్లినప్పుడు, ప్రతి ఒక్కరూ వారి తలలను పట్టుకోవడం ప్రారంభిస్తారు. ఎందుకంటే డిస్క్ స్లో, జ్ఞాపకశక్తి వేగంగా ఉంటుందన్న నిజం చిన్నప్పటి నుంచి అందరికీ తెలిసిందే. మరియు డేటాబేస్ డిస్క్ పనితీరు సమస్యలను కలిగి ఉంటుందని అందరికీ తెలుసు.
డిస్క్ నెమ్మదిగా ఉన్నందున చెక్‌పాయింట్‌ల స్పైక్‌లతో అనుబంధించబడిన ప్రధాన PostgreSQL పనితీరు సమస్య ఏర్పడదు. మెమరీ మరియు డిస్క్ బ్యాండ్‌విడ్త్ సమతుల్యంగా లేనందున ఇది చాలా మటుకు కావచ్చు. అయితే, అవి వేర్వేరు ప్రదేశాలలో సమతుల్యంగా ఉండకపోవచ్చు. PostgreSQL కాన్ఫిగర్ చేయబడలేదు, OS కాన్ఫిగర్ చేయబడలేదు, హార్డ్‌వేర్ కాన్ఫిగర్ చేయబడలేదు మరియు హార్డ్‌వేర్ తప్పుగా ఉంది. మరియు ప్రతిదీ సరిగ్గా జరిగితే మాత్రమే ఈ సమస్య జరగదు, అనగా లోడ్ లేదు, లేదా సెట్టింగులు మరియు హార్డ్‌వేర్ బాగా ఎంపిక చేయబడి ఉంటాయి.
ఇది ఏమిటి మరియు అది ఎలా కనిపిస్తుంది? సాధారణంగా PostgreSQLతో పనిచేసే వ్యక్తులు ఈ విషయంలో ఒకటి కంటే ఎక్కువసార్లు ప్రవేశించారు. నేను వివరిస్తాను. నేను చెప్పినట్లు, షేర్డ్ మెమరీలోని మురికి పేజీలను డిస్క్‌కి డంప్ చేయడానికి PostgreSQL క్రమానుగతంగా చెక్‌పాయింట్లు చేస్తుంది. మనకు పెద్ద మొత్తంలో భాగస్వామ్య మెమరీ ఉంటే, చెక్‌పాయింట్ డిస్క్‌పై తీవ్రమైన ప్రభావాన్ని చూపడం ప్రారంభిస్తుంది, ఎందుకంటే ఇది ఈ పేజీలను fsyncతో డంప్ చేస్తుంది. ఇది కెర్నల్ బఫర్‌లోకి వస్తుంది మరియు fsyncని ఉపయోగించి డిస్క్‌లకు వ్రాయబడుతుంది. మరియు ఈ వ్యాపారం యొక్క పరిమాణం పెద్దగా ఉంటే, అప్పుడు మేము అసహ్యకరమైన ప్రభావాన్ని గమనించవచ్చు, అవి డిస్కుల యొక్క చాలా పెద్ద వినియోగం.
ఇక్కడ నా దగ్గర రెండు చిత్రాలు ఉన్నాయి. అది ఏమిటో ఇప్పుడు వివరిస్తాను. ఇవి రెండు సమయ-సంబంధిత గ్రాఫ్‌లు. మొదటి గ్రాఫ్ డిస్క్ వినియోగం. ఇక్కడ ఈ సమయంలో దాదాపు 90%కి చేరుకుంటుంది. మీరు ఫిజికల్ డిస్క్‌లతో డేటాబేస్ వైఫల్యాన్ని కలిగి ఉంటే, 90% వద్ద RAID కంట్రోలర్ వినియోగంతో, ఇది చెడ్డ వార్త. అంటే కొంచెం ఎక్కువ మరియు అది 100కి చేరుకుంటుంది మరియు I/O ఆగిపోతుంది.
మీకు డిస్క్ శ్రేణి ఉంటే, అది కొద్దిగా భిన్నమైన కథ. ఇది ఎలా కాన్ఫిగర్ చేయబడింది, ఇది ఏ రకమైన శ్రేణి, మొదలైన వాటిపై ఆధారపడి ఉంటుంది.
మరియు సమాంతరంగా, అంతర్గత పోస్ట్‌గ్రెస్ వీక్షణ నుండి గ్రాఫ్ ఇక్కడ కాన్ఫిగర్ చేయబడింది, ఇది చెక్‌పాయింట్ ఎలా జరుగుతుందో తెలియజేస్తుంది. మరియు ఇక్కడ ఆకుపచ్చ రంగు ఎన్ని బఫర్‌లు, ఈ మురికి పేజీలు, ఆ సమయంలో సమకాలీకరణ కోసం ఈ చెక్‌పాయింట్‌కు చేరుకున్నాయి. మరియు ఇక్కడ మీరు తెలుసుకోవలసిన ప్రధాన విషయం ఇది. మనకు ఇక్కడ చాలా పేజీలు ఉన్నాయని మేము చూస్తాము మరియు ఏదో ఒక సమయంలో మేము బోర్డుని కొట్టాము, అంటే, మేము వ్రాసాము మరియు వ్రాసాము, ఇక్కడ డిస్క్ సిస్టమ్ స్పష్టంగా చాలా బిజీగా ఉంది. మరియు మా తనిఖీ కేంద్రం డిస్క్‌పై చాలా బలమైన ప్రభావాన్ని చూపుతుంది. ఆదర్శవంతంగా, పరిస్థితి ఇలాగే ఉండాలి, అంటే మాకు ఇక్కడ తక్కువ రికార్డింగ్ ఉంది. మరియు మేము దీన్ని సెట్టింగ్‌లతో పరిష్కరించవచ్చు, తద్వారా ఇది ఇలాగే కొనసాగుతుంది. అంటే, రీసైక్లింగ్ చిన్నది, కానీ ఎక్కడో మనం ఇక్కడ ఏదో వ్రాస్తున్నాము.
ఈ సమస్యను అధిగమించడానికి ఏమి చేయాలి? మీరు డేటాబేస్ క్రింద IOని ఆపివేసినట్లయితే, వారి అభ్యర్థనలను నెరవేర్చడానికి వచ్చిన వినియోగదారులందరూ వేచి ఉంటారని దీని అర్థం.
మీరు Linux దృక్కోణం నుండి చూస్తే, మీరు మంచి హార్డ్‌వేర్‌ని తీసుకుంటే, దాన్ని సరిగ్గా కాన్ఫిగర్ చేసి, PostgreSQLని సాధారణంగా కాన్ఫిగర్ చేస్తే, ఈ చెక్‌పాయింట్‌లను తక్కువ తరచుగా చేస్తుంది, కాలక్రమేణా వాటిని ఒకదానికొకటి విస్తరించండి, ఆపై మీరు డిఫాల్ట్ డెబియన్ పారామితులలోకి అడుగు పెట్టండి. చాలా Linux పంపిణీల కోసం, ఇది చిత్రం: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
దాని అర్థం ఏమిటి? కెర్నల్ 2.6 నుండి ఒక ఫ్లషింగ్ డెమోన్ కనిపించింది. Pdglush, ఎవరు ఉపయోగిస్తున్నారనే దానిపై ఆధారపడి, ఇది కెర్నల్ బఫర్ నుండి డర్టీ పేజీలను బ్యాక్‌గ్రౌండ్ విస్మరించడంలో నిమగ్నమై ఉంటుంది మరియు బ్యాక్‌గ్రౌండ్ విస్మరించడం సహాయం చేయనప్పుడు డర్టీ పేజీలను విస్మరించాల్సిన అవసరం వచ్చినప్పుడు విస్మరిస్తుంది.
నేపథ్యం ఎప్పుడు వస్తుంది? సర్వర్‌లో అందుబాటులో ఉన్న మొత్తం RAMలో 10% కెర్నల్ బఫర్‌లోని మురికి పేజీలచే ఆక్రమించబడినప్పుడు, ప్రత్యేక రైట్-ఆఫ్ ఫంక్షన్ నేపథ్యంలో పిలువబడుతుంది. ఇది ఎందుకు నేపథ్యం? పారామీటర్‌గా, ఎన్ని పేజీలను వ్రాయాలనేది పరిగణనలోకి తీసుకుంటుంది. మరియు, అతను N పేజీలను వ్రాస్తాడు. మరియు కొంతకాలం ఈ విషయం నిద్రపోతుంది. ఆపై ఆమె మళ్లీ వచ్చి మరికొన్ని పేజీలను కాపీ చేస్తుంది.
ఇది చాలా సాధారణ కథ. ఇక్కడ సమస్య స్విమ్మింగ్ పూల్ వంటిది, అది ఒక పైపులోకి పోయినప్పుడు, అది మరొకదానిలోకి ప్రవహిస్తుంది. మా చెక్‌పాయింట్ వచ్చింది మరియు అది విస్మరించడానికి కొన్ని మురికి పేజీలను పంపినట్లయితే, క్రమంగా మొత్తం విషయం కెర్నల్ బఫర్ pgflush నుండి చక్కగా పరిష్కరించబడుతుంది.
ఈ మురికి పేజీలు కూడబెట్టడం కొనసాగితే, అవి 20% వరకు పేరుకుపోతాయి, దాని తర్వాత OS ప్రాధాన్యత మొత్తం డిస్క్‌కు వ్రాయడం, ఎందుకంటే శక్తి విఫలమవుతుంది మరియు ప్రతిదీ మనకు చెడుగా ఉంటుంది. మేము ఈ డేటాను కోల్పోతాము, ఉదాహరణకు.
ఉపాయం ఏమిటి? ఉపాయం ఏమిటంటే, ఆధునిక ప్రపంచంలోని ఈ పారామితులు మెషీన్‌లో ఉన్న మొత్తం RAMలో 20 మరియు 10%, మీ వద్ద ఉన్న ఏదైనా డిస్క్ సిస్టమ్ యొక్క నిర్గమాంశ పరంగా అవి ఖచ్చితంగా భయంకరమైనవి.
మీకు 128 GB RAM ఉందని ఊహించుకోండి. మీ డిస్క్ సిస్టమ్‌లో 12,8 GB వస్తుంది. మరియు మీరు అక్కడ ఏ కాష్‌ని కలిగి ఉన్నా, మీరు అక్కడ ఏ శ్రేణిని కలిగి ఉన్నా, అవి ఎక్కువ కాలం ఉండవు.
కాబట్టి, మీ RAID కంట్రోలర్ సామర్థ్యాల ఆధారంగా మీరు వెంటనే ఈ సంఖ్యలను సర్దుబాటు చేయాలని మేము సిఫార్సు చేస్తున్నాము. 512 MB కాష్ ఉన్న కంట్రోలర్ కోసం నేను వెంటనే ఇక్కడ సిఫార్సు చేసాను.
ప్రతిదీ చాలా సరళంగా పరిగణించబడుతుంది. మీరు vm.dirty_backgroundని బైట్‌లలో ఉంచవచ్చు. మరియు ఈ సెట్టింగ్‌లు మునుపటి రెండింటిని రద్దు చేస్తాయి. నిష్పత్తి డిఫాల్ట్‌గా ఉంటుంది, లేదా బైట్‌లు ఉన్నవి యాక్టివేట్ చేయబడితే, బైట్‌లు ఉన్నవి పని చేస్తాయి. కానీ నేను DBA కన్సల్టెంట్‌ని మరియు విభిన్న క్లయింట్‌లతో పని చేస్తున్నందున, నేను స్ట్రాస్‌ని గీయడానికి ప్రయత్నిస్తాను మరియు అందువల్ల బైట్‌లలో ఉంటే, బైట్‌లలో. మంచి అడ్మిన్ సర్వర్కు ఎక్కువ మెమరీని జోడించరని, దాన్ని రీబూట్ చేయరని మరియు ఫిగర్ అలాగే ఉంటుందని ఎవరూ హామీ ఇవ్వలేదు. ఈ సంఖ్యలను లెక్కించండి, తద్వారా ప్రతిదీ హామీతో సరిపోతుంది.
మీరు సరిపోకపోతే ఏమి జరుగుతుంది? ఏదైనా ఫ్లషింగ్ సమర్థవంతంగా నిలిపివేయబడిందని నేను వ్రాసాను, కానీ వాస్తవానికి ఇది ప్రసంగం యొక్క చిత్రం. ఆపరేటింగ్ సిస్టమ్‌లో పెద్ద సమస్య ఉంది - దీనికి చాలా డర్టీ పేజీలు ఉన్నాయి, కాబట్టి మీ క్లయింట్లు ఉత్పత్తి చేసే IO సమర్థవంతంగా నిలిపివేయబడుతుంది, అనగా డేటాబేస్కు sql ప్రశ్నను పంపడానికి అప్లికేషన్ వచ్చింది, అది వేచి ఉంది. డేటాబేస్ చెక్‌పాయింట్ ద్వారా ఆక్రమించబడినందున దానికి ఏదైనా ఇన్‌పుట్/అవుట్‌పుట్ అతి తక్కువ ప్రాధాన్యతనిస్తుంది. మరియు ఆమె ఎప్పుడు పూర్తి చేస్తుందో పూర్తిగా అస్పష్టంగా ఉంది. మరియు మీరు నాన్-బ్యాక్‌గ్రౌండ్ ఫ్లషింగ్‌ను సాధించినప్పుడు, మీ IO మొత్తం దాని ద్వారా ఆక్రమించబడిందని అర్థం. మరియు అది ముగిసే వరకు, మీరు ఏమీ చేయరు.
ఈ నివేదిక పరిధికి మించిన మరో రెండు ముఖ్యమైన అంశాలు ఇక్కడ ఉన్నాయి. ఈ సెట్టింగ్‌లు postgresql.confలోని సెట్టింగ్‌లతో సరిపోలాలి, అనగా చెక్‌పాయింట్ సెట్టింగ్‌లు. మరియు మీ డిస్క్ సిస్టమ్ తగినంతగా కాన్ఫిగర్ చేయబడాలి. మీకు RAIDలో కాష్ ఉంటే, అది తప్పనిసరిగా బ్యాటరీని కలిగి ఉండాలి. ప్రజలు బ్యాటరీ లేకుండా మంచి కాష్‌తో RAIDని కొనుగోలు చేస్తారు. మీరు RAIDలో SSDలను కలిగి ఉంటే, అవి తప్పనిసరిగా సర్వర్‌గా ఉండాలి, అక్కడ కెపాసిటర్లు ఉండాలి. ఇక్కడ వివరణాత్మక చెక్‌లిస్ట్ ఉంది. ఈ లింక్ PostgreSQLలో పనితీరు డిస్క్‌ను ఎలా కాన్ఫిగర్ చేయాలనే దానిపై నా నివేదికను కలిగి ఉంది. అక్కడ ఈ చెక్‌లిస్ట్‌లన్నీ ఉన్నాయి.
ఇంకా ఏమి జీవితాన్ని చాలా కష్టతరం చేస్తుంది? ఇవి రెండు పారామితులు. అవి సాపేక్షంగా కొత్తవి. డిఫాల్ట్‌గా, వాటిని వివిధ అప్లికేషన్‌లలో చేర్చవచ్చు. మరియు అవి తప్పుగా ఆన్ చేయబడితే జీవితాన్ని అంతే కష్టతరం చేస్తాయి.
సాపేక్షంగా రెండు కొత్త విషయాలు ఉన్నాయి. వారు ఇప్పటికే మూడవ కోర్లలో కనిపించారు. ఇది నానోసెకన్లలో sched_migration_cost మరియు sched_autogroup_enabled, ఇది డిఫాల్ట్‌గా ఒకటి.
మరియు వారు మీ జీవితాన్ని ఎలా నాశనం చేస్తారు? షెడ్_మైగ్రేషన్_కాస్ట్ అంటే ఏమిటి? Linuxలో, షెడ్యూలర్ ప్రక్రియను ఒక CPU నుండి మరొకదానికి మార్చవచ్చు. మరియు ప్రశ్నలను అమలు చేసే PostgreSQL కోసం, మరొక CPUకి మారడం పూర్తిగా అస్పష్టంగా ఉంది. ఆపరేటింగ్ సిస్టమ్ దృక్కోణం నుండి, మీరు ఓపెన్ ఆఫీస్ మరియు టెర్మినల్ మధ్య విండోలను మార్చినప్పుడు, ఇది మంచిది, కానీ డేటాబేస్ కోసం ఇది చాలా చెడ్డది. అందువల్ల, మైగ్రేషన్_వ్యయాన్ని కొంత పెద్ద విలువకు, కనీసం కొన్ని వేల నానోసెకన్లకు సెట్ చేయడం సహేతుకమైన విధానం.
షెడ్యూలర్‌కి దీని అర్థం ఏమిటి? ఈ సమయంలో ప్రక్రియ ఇంకా వేడిగా ఉందని పరిగణించబడుతుంది. అంటే, మీరు చాలా కాలంగా ఏదైనా చేస్తున్న లాంగ్-రన్ లావాదేవీని కలిగి ఉంటే, షెడ్యూలర్ దీన్ని అర్థం చేసుకుంటారు. ఈ గడువు ముగిసే వరకు, ఈ ప్రక్రియను ఎక్కడికీ తరలించాల్సిన అవసరం లేదని అతను ఊహిస్తాడు. అదే సమయంలో ప్రక్రియ ఏదైనా చేస్తే, అది ఎక్కడికీ తరలించబడదు, దానికి కేటాయించిన CPUలో ఇది నిశ్శబ్దంగా పని చేస్తుంది. మరియు ఫలితం అద్భుతమైనది.
రెండవ పాయింట్ ఆటోగ్రూప్. ఆధునిక డేటాబేస్‌లకు సంబంధం లేని నిర్దిష్ట పనిభారాల కోసం మంచి ఆలోచన ఉంది - ఇది వర్చువల్ టెర్మినల్ ద్వారా ప్రాసెస్‌లను సమూహపరచడం. ఇది కొన్ని పనులకు అనుకూలమైనది. ఆచరణలో, PostgreSQL అనేది ఒకే టెర్మినల్ నుండి నడిచే ప్రీఫోర్క్‌తో కూడిన బహుళ-ప్రాసెస్ సిస్టమ్. మీకు లాక్ రైటర్, చెక్‌పాయింట్ ఉన్నాయి మరియు మీ క్లయింట్ అభ్యర్థనలన్నీ ఒక CPUకి ఒక షెడ్యూలర్‌గా సమూహం చేయబడతాయి. మరియు ఒకరికొకరు జోక్యం చేసుకోవడానికి మరియు అతనిని ఎక్కువసేపు ఆక్రమించుకోవడానికి వారు అతను స్వేచ్ఛగా ఉండటానికి అక్కడ ఏకగ్రీవంగా వేచి ఉంటారు. అలాంటి లోడ్ విషయంలో పూర్తిగా అనవసరమైన కథ ఇది కాబట్టి దాన్ని ఆపివేయాలి.
నా సహోద్యోగి అలెక్సీ లెసోవ్స్కీ సాధారణ pgbenchతో పరీక్షలు చేసాడు, అక్కడ అతను మైగ్రేషన్_ఖర్చును ఒక క్రమంలో పెంచి ఆటోగ్రూప్‌ని ఆఫ్ చేసాడు. చెడ్డ హార్డ్‌వేర్‌పై వ్యత్యాసం దాదాపు 10%. పోస్ట్‌గ్రెస్ మెయిలింగ్ జాబితాపై చర్చ జరుగుతోంది, ఇక్కడ వ్యక్తులు ప్రశ్న వేగానికి ఇలాంటి మార్పుల ఫలితాలను ఇస్తారు ప్రభావితం 50%. ఇలాంటి కథలు చాలానే ఉన్నాయి.
చివరగా, పవర్ సేవింగ్ పాలసీ గురించి. మంచి విషయం ఏమిటంటే Linuxని ఇప్పుడు ల్యాప్‌టాప్‌లో ఉపయోగించవచ్చు. మరియు ఇది బ్యాటరీని బాగా ఉపయోగిస్తుంది. కానీ అకస్మాత్తుగా ఇది సర్వర్‌లో కూడా జరగవచ్చు.
అంతేకాకుండా, మీరు కొంతమంది హోస్టర్ నుండి సర్వర్‌లను అద్దెకు తీసుకుంటే, మీరు మెరుగైన పనితీరును కలిగి ఉన్నారని "మంచి" హోస్టర్‌లు పట్టించుకోరు. వారి పని వారి ఇనుము సాధ్యమైనంత సమర్ధవంతంగా ఉపయోగించబడుతుందని నిర్ధారించడం. అందువల్ల, డిఫాల్ట్‌గా వారు ఆపరేటింగ్ సిస్టమ్‌లో ల్యాప్‌టాప్ పవర్ సేవింగ్ మోడ్‌ను ప్రారంభించగలరు.
మీరు అధిక లోడ్‌లో ఉన్న డేటాబేస్‌తో సర్వర్‌లో ఈ విషయాన్ని ఉపయోగిస్తే, మీ ఎంపిక acpi_cpufreq + permormance. ఆన్‌డిమాండ్‌తో కూడా సమస్యలు ఉంటాయి.
Intel_pstate కొద్దిగా భిన్నమైన డ్రైవర్. మరియు ఇప్పుడు దీనికి ప్రాధాన్యత ఇవ్వబడింది, ఎందుకంటే ఇది తరువాత మరియు మెరుగ్గా పనిచేస్తుంది.
మరియు, దాని ప్రకారం, గవర్నర్ పనితీరు మాత్రమే. Ondemand, powersave మరియు మిగతావన్నీ మీ గురించి కాదు.
మీరు పవర్‌సేవ్‌ని ఎనేబుల్ చేస్తే PostgreSQL యొక్క వివరణ విశ్లేషణ ఫలితాలు అనేక ఆర్డర్‌ల పరిమాణంలో తేడా ఉండవచ్చు, ఎందుకంటే ఆచరణాత్మకంగా మీ డేటాబేస్ క్రింద ఉన్న CPU పూర్తిగా అనూహ్య రీతిలో రన్ అవుతుంది.
ఈ అంశాలు డిఫాల్ట్‌గా చేర్చబడవచ్చు. వారు దానిని డిఫాల్ట్‌గా ఆన్ చేసారో లేదో చూడటానికి జాగ్రత్తగా చూడండి. ఇది నిజంగా పెద్ద సమస్య కావచ్చు.
చివరికి, ప్రతిరోజూ ఈ విషయంలో ముందుకు సాగుతున్న మాక్స్ బోగుక్ మరియు అలెక్సీ లెసోవ్స్కీ అనే మా పోస్గ్రెస్‌క్యూఎల్-కన్సల్టింగ్ డిబిఎ టీమ్‌కి చెందిన కుర్రాళ్లకు నేను ధన్యవాదాలు చెప్పాలనుకుంటున్నాను. మరియు మేము మా క్లయింట్‌ల కోసం మేము చేయగలిగినంత ఉత్తమంగా చేయడానికి ప్రయత్నిస్తాము, తద్వారా ఇది వారి కోసం పని చేస్తుంది. ఇది విమానయాన భద్రతా సూచనల మాదిరిగానే ఉంటుంది. ఇక్కడ ప్రతిదీ రక్తంతో వ్రాయబడింది. ఈ గింజల్లో ప్రతి ఒక్కటి ఏదో ఒక రకమైన సమస్య యొక్క ప్రక్రియలో కనుగొనబడింది. వాటిని మీతో పంచుకోవడం నాకు సంతోషంగా ఉంది.
ప్రశ్నలు:
ధన్యవాదాలు! ఉదాహరణకు, ఒక కంపెనీ డబ్బును ఆదా చేసి, డేటాబేస్ మరియు అప్లికేషన్ లాజిక్‌ను ఒక సర్వర్‌లో ఉంచాలనుకుంటే లేదా కంపెనీ మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌ల యొక్క ఫ్యాషన్ ట్రెండ్‌ను అనుసరిస్తే, దీనిలో PostgreSQL ఒక కంటైనర్‌లో నడుస్తుంది. ఉపాయం ఏమిటి? Sysctl ప్రపంచవ్యాప్తంగా మొత్తం కెర్నల్‌ను ప్రభావితం చేస్తుంది. sysctls ఏదో ఒకవిధంగా వర్చువలైజ్ చేయబడటం గురించి నేను వినలేదు, తద్వారా అవి కంటైనర్‌లో విడిగా పనిచేస్తాయి. ఒక cgroup మాత్రమే ఉంది మరియు అక్కడ నియంత్రణలో భాగం మాత్రమే ఉంది. దీనితో మీరు ఎలా జీవించగలరు? లేదా మీకు పనితీరు కావాలంటే, ప్రత్యేక హార్డ్‌వేర్ సర్వర్‌లో PostgreSQLని అమలు చేసి, దాన్ని ట్యూన్ చేయాలా?
మేము మీ ప్రశ్నకు మూడు విధాలుగా సమాధానమిచ్చాము. మేము ట్యూన్ చేయగల హార్డ్‌వేర్ సర్వర్ గురించి మాట్లాడకపోతే, విశ్రాంతి తీసుకోండి, ఈ సెట్టింగ్‌లు లేకుండా ప్రతిదీ బాగా పని చేస్తుంది. మీరు ఈ సెట్టింగులను చేయవలసిన అటువంటి లోడ్ని కలిగి ఉంటే, అప్పుడు మీరు ఈ సెట్టింగుల కంటే ముందుగా ఐరన్ సర్వర్కు వస్తారు.
సమస్య ఏమిటి? ఇది వర్చువల్ మెషీన్ అయితే, చాలా మటుకు మీకు చాలా సమస్యలు ఉంటాయి, ఉదాహరణకు, చాలా వర్చువల్ మెషీన్లలో డిస్క్ యొక్క జాప్యం చాలా అస్థిరంగా ఉంటుంది. డిస్క్ త్రూపుట్ బాగానే ఉన్నప్పటికీ, చెక్‌పాయింట్ సమయంలో లేదా WALకి వ్రాసే సమయంలో జరిగిన సగటు త్రూపుట్‌ను పెద్దగా ప్రభావితం చేయని I/O లావాదేవీ విఫలమైంది, అప్పుడు డేటాబేస్ దీని వల్ల బాగా నష్టపోతుంది. మరియు మీరు ఈ సమస్యలను ఎదుర్కొనే ముందు మీరు దీనిని గమనించవచ్చు.
మీకు అదే సర్వర్‌లో NGINX ఉంటే, మీకు కూడా అదే సమస్య ఉంటుంది. అతను షేర్డ్ మెమరీ కోసం పోరాడుతాడు. మరియు మీరు ఇక్కడ వివరించిన సమస్యలను పొందలేరు.
కానీ మరోవైపు, ఈ పారామితులలో కొన్ని ఇప్పటికీ మీకు సంబంధించినవిగా ఉంటాయి. ఉదాహరణకు, sysctlతో dirty_ratioని సెట్ చేయండి, తద్వారా ఇది చాలా క్రేజీగా ఉండదు - ఏ సందర్భంలోనైనా, ఇది సహాయపడుతుంది. ఒక మార్గం లేదా మరొకటి, మీరు డిస్క్‌తో పరస్పర చర్యను కలిగి ఉంటారు. మరియు అది తప్పు నమూనా ప్రకారం ఉంటుంది. నేను చూపిన పారామితులకు ఇది సాధారణంగా డిఫాల్ట్. మరియు ఏ సందర్భంలోనైనా వాటిని మార్చడం మంచిది.
కానీ NUMAతో సమస్యలు ఉండవచ్చు. ఉదాహరణకు, VmWare, సరిగ్గా వ్యతిరేక సెట్టింగ్‌లతో NUMAతో బాగా పనిచేస్తుంది. మరియు ఇక్కడ మీరు ఎంచుకోవాలి - ఇనుప సర్వర్ లేదా ఇనుము లేనిది.
నాకు Amazon AWSకి సంబంధించిన ప్రశ్న ఉంది. వారు ముందే కాన్ఫిగర్ చేసిన చిత్రాలను కలిగి ఉన్నారు. వాటిలో ఒకటి Amazon RDS. వారి ఆపరేటింగ్ సిస్టమ్ కోసం ఏవైనా అనుకూల సెట్టింగ్‌లు ఉన్నాయా?
అక్కడ సెట్టింగ్‌లు ఉన్నాయి, కానీ అవి వేర్వేరు సెట్టింగ్‌లు. డేటాబేస్ ఈ విషయాన్ని ఎలా ఉపయోగిస్తుందో ఇక్కడ మేము ఆపరేటింగ్ సిస్టమ్‌ను కాన్ఫిగర్ చేస్తాము. మరియు మనం ఇప్పుడు ఎక్కడికి వెళ్లాలో నిర్ణయించే పారామితులు ఉన్నాయి, షేపింగ్ వంటివి. అంటే, మనకు చాలా వనరులు కావాలి, ఇప్పుడు మనం వాటిని తింటాము. దీని తర్వాత, Amazon RDS ఈ వనరులను కఠినతరం చేస్తుంది మరియు పనితీరు అక్కడ పడిపోతుంది. ఈ విషయంలో ప్రజలు ఎలా గందరగోళానికి గురవుతున్నారో వ్యక్తిగత కథనాలు ఉన్నాయి. కొన్నిసార్లు చాలా విజయవంతంగా కూడా. కానీ దీనికి OS సెట్టింగ్‌లతో సంబంధం లేదు. ఇది క్లౌడ్‌ను హ్యాక్ చేయడం లాంటిది. అది వేరే కథ.
భారీ TLBతో పోలిస్తే పారదర్శక భారీ పేజీలు ఎందుకు ప్రభావం చూపవు?
ఇవ్వకు. దీనిని అనేక విధాలుగా వివరించవచ్చు. కానీ వాస్తవానికి వారు దానిని ఇవ్వరు. PostgreSQL చరిత్ర ఏమిటి? ప్రారంభంలో, ఇది షేర్డ్ మెమరీ యొక్క పెద్ద భాగాన్ని కేటాయిస్తుంది. అవి పారదర్శకంగా ఉన్నాయా లేదా అనేది పూర్తిగా అప్రస్తుతం. వారు ప్రారంభంలో నిలబడటం ప్రతిదీ వివరిస్తుంది. మరియు చాలా మెమరీ ఉంటే మరియు మీరు షేర్డ్_మెమొరీ విభాగాన్ని పునర్నిర్మించవలసి ఉంటే, అప్పుడు పారదర్శక భారీ పేజీలు సంబంధితంగా ఉంటాయి. PostgreSQLలో, ఇది ప్రారంభంలో భారీ భాగంతో కేటాయించబడుతుంది మరియు అంతే, ఆపై ప్రత్యేకంగా ఏమీ జరగదు. మీరు దీన్ని ఉపయోగించుకోవచ్చు, కానీ షేర్ చేసిన_మెమరీ ఏదైనా మళ్లీ కేటాయించినప్పుడు దాని అవినీతిని పొందే అవకాశం ఉంది. PostgreSQLకి దీని గురించి తెలియదు.
మూలం: www.habr.com