PostgreSQL પ્રદર્શન સુધારવા માટે Linux ટ્યુનિંગ. ઇલ્યા કોસ્મોડેમિયાંસ્કી

ઇલ્યા કોસ્મોડેમિઆન્સ્કી દ્વારા 2015 ના અહેવાલની ટ્રાન્સક્રિપ્ટ "પોસ્ટગ્રેએસક્યુએલ પ્રદર્શનને સુધારવા માટે લિનક્સ ટ્યુનિંગ"

અસ્વીકરણ: હું નોંધું છું કે આ અહેવાલ નવેમ્બર 2015 નો છે - 4 વર્ષથી વધુ સમય વીતી ગયો છે અને ઘણો સમય વીતી ગયો છે. અહેવાલમાં ચર્ચા કરેલ સંસ્કરણ 9.4 હવે સમર્થિત નથી. છેલ્લા 4 વર્ષોમાં, PostgreSQL ની 5 નવી રીલીઝ કરવામાં આવી છે, અને Linux કર્નલની 15 આવૃત્તિઓ રીલીઝ કરવામાં આવી છે. જો તમે આ ફકરાઓને ફરીથી લખો છો, તો તમે એક અલગ રિપોર્ટ સાથે સમાપ્ત થશો. પરંતુ અહીં અમે PostgreSQL માટે મૂળભૂત Linux ટ્યુનિંગને ધ્યાનમાં લઈએ છીએ, જે આજે પણ સુસંગત છે.

મારું નામ ઇલ્યા કોસ્મોડેમિયાંસ્કી છે. હું PostgreSQL-કન્સલ્ટિંગમાં કામ કરું છું. અને હવે હું સામાન્ય રીતે ડેટાબેસેસ અને ખાસ કરીને PostgreSQL ના સંબંધમાં Linux સાથે શું કરવું તે વિશે થોડી વાત કરીશ, કારણ કે સિદ્ધાંતો એકદમ સમાન છે.

આપણે શું વાત કરીશું? જો તમે PostgreSQL સાથે વાતચીત કરો છો, તો અમુક અંશે તમારે UNIX એડમિન બનવાની જરૂર છે. તેનો અર્થ શું છે? જો આપણે Oracle અને PostgreSQL ની સરખામણી કરીએ, તો Oracle માં તમારે 80% DBA ડેટાબેઝ એડમિન અને 20% Linux એડમિન હોવું જરૂરી છે.

PostgreSQL સાથે તે થોડું વધુ જટિલ છે. PostgreSQL સાથે તમને Linux કેવી રીતે કામ કરે છે તેની વધુ સારી સમજ હોવી જરૂરી છે. અને તે જ સમયે, લોકોમોટિવ પછી થોડું ચલાવો, કારણ કે તાજેતરમાં બધું ખૂબ સરસ રીતે અપડેટ કરવામાં આવ્યું છે. અને નવા કર્નલ રીલીઝ થાય છે, અને નવી કાર્યક્ષમતા દેખાય છે, પ્રદર્શન સુધરે છે, વગેરે.

શા માટે આપણે Linux વિશે વાત કરી રહ્યા છીએ? બિલકુલ નહીં કારણ કે અમે Linux કોન્ફરન્સ પીટરમાં છીએ, પરંતુ કારણ કે આધુનિક પરિસ્થિતિઓમાં સામાન્ય રીતે ડેટાબેસેસ અને ખાસ કરીને PostgreSQL નો ઉપયોગ કરવા માટેની સૌથી ન્યાયી ઓપરેટિંગ સિસ્ટમો પૈકીની એક Linux છે. કારણ કે ફ્રીબીએસડી, કમનસીબે, કેટલીક ખૂબ જ વિચિત્ર દિશામાં વિકાસ કરી રહ્યું છે. અને પ્રદર્શન અને અન્ય ઘણી વસ્તુઓ બંને સાથે સમસ્યાઓ હશે. વિન્ડોઝ પર પોસ્ટગ્રેએસક્યુએલનું પ્રદર્શન સામાન્ય રીતે એક અલગ ગંભીર સમસ્યા છે, તે હકીકત પર આધારિત છે કે વિન્ડોઝ પાસે યુનિક્સ જેવી જ વહેંચાયેલ મેમરી નથી, જ્યારે પોસ્ટગ્રેએસક્યુએલ આ બધા સાથે જોડાયેલું છે, કારણ કે તે બહુ-પ્રક્રિયા સિસ્ટમ છે.

અને મને લાગે છે કે સૌને સોલારિસ જેવા એક્સોટિક્સમાં ઓછો રસ છે, તેથી ચાલો જઈએ.

તમે કર્નલ કેવી રીતે બનાવો છો તેના આધારે આધુનિક Linux વિતરણમાં 1 થી વધુ syctl વિકલ્પો છે. તે જ સમયે, જો આપણે વિવિધ બદામ જોઈએ, તો આપણે ઘણી રીતે કંઈક ગોઠવી શકીએ છીએ. તેમને કેવી રીતે માઉન્ટ કરવું તેના પર ફાઇલ સિસ્ટમ પરિમાણો છે. જો તમને તે કેવી રીતે શરૂ કરવું તે વિશે પ્રશ્નો હોય: BIOS માં શું સક્ષમ કરવું, હાર્ડવેરને કેવી રીતે ગોઠવવું વગેરે.

આ એક ખૂબ જ વિશાળ વોલ્યુમ છે જેની ચર્ચા ઘણા દિવસો સુધી થઈ શકે છે, અને એક ટૂંકા અહેવાલમાં નહીં, પરંતુ હવે હું મહત્વપૂર્ણ બાબતો પર ધ્યાન કેન્દ્રિત કરીશ, તે રેક્સને કેવી રીતે ટાળવું કે જે તમને Linux પર તમારા ડેટાબેઝનો સારી રીતે ઉપયોગ કરવાથી અટકાવવાની ખાતરી આપે છે જો તમે તેમને સુધારશો નહીં. અને તે જ સમયે, એક મહત્વપૂર્ણ મુદ્દો એ છે કે ડેટાબેઝ માટે યોગ્ય સેટિંગ્સમાં ઘણા ડિફૉલ્ટ પરિમાણો શામેલ નથી. એટલે કે, મૂળભૂત રીતે તે ખરાબ રીતે કામ કરશે અથવા બિલકુલ નહીં.

Linux માં કયા પરંપરાગત ટ્યુનિંગ લક્ષ્યો છે? મને લાગે છે કે તમે બધા લિનક્સ એડમિનિસ્ટ્રેશન સાથે કામ કરી રહ્યા હોવાથી, લક્ષ્યો શું છે તે સમજાવવાની કોઈ ખાસ જરૂર નથી.

તમે ટ્યુન કરી શકો છો:

• સી.પી. યુ.
• મેમરી.
• સંગ્રહ.
• અન્ય. અમે નાસ્તા માટે અંતે આ વિશે વાત કરીશું. ઉદાહરણ તરીકે, ઉર્જા બચત નીતિ જેવા પરિમાણો ખૂબ જ અણધારી રીતે પ્રભાવિત કરી શકે છે અને સૌથી સુખદ રીતે નહીં.

PostgreSQL અને સામાન્ય રીતે ડેટાબેઝની વિશિષ્ટતાઓ શું છે? સમસ્યા એ છે કે તમે કોઈપણ વ્યક્તિગત અખરોટને ટ્વિક કરી શકતા નથી અને જુઓ કે અમારું પ્રદર્શન નોંધપાત્ર રીતે સુધર્યું છે.

હા, આવા ગેજેટ્સ છે, પરંતુ ડેટાબેઝ એક જટિલ વસ્તુ છે. તે સર્વર પાસેના તમામ સંસાધનો સાથે ક્રિયાપ્રતિક્રિયા કરે છે અને સંપૂર્ણ રીતે ક્રિયાપ્રતિક્રિયા કરવાનું પસંદ કરે છે. જો તમે હોસ્ટ ઓએસનો ઉપયોગ કેવી રીતે કરવો તે અંગે ઓરેકલની વર્તમાન ભલામણો જોશો, તો તે તે મોંગોલિયન અવકાશયાત્રી વિશેની મજાક જેવું હશે - કૂતરાને ખવડાવો અને કંઈપણ સ્પર્શ કરશો નહીં. ચાલો ડેટાબેઝને તમામ સંસાધનો આપીએ, ડેટાબેઝ પોતે જ બધું ગોઠવશે.

સૈદ્ધાંતિક રીતે, અમુક અંશે પરિસ્થિતિ PostgreSQL સાથે બરાબર સમાન છે. તફાવત એ છે કે ડેટાબેઝ હજુ સુધી પોતાના માટે તમામ સંસાધનો લેવા માટે સક્ષમ નથી, એટલે કે ક્યાંક લિનક્સ સ્તરે તમારે તેને જાતે જ સૉર્ટ કરવાની જરૂર છે.

મુખ્ય વિચાર એ છે કે કોઈ એક લક્ષ્ય પસંદ કરવું અને તેને ટ્યુન કરવાનું શરૂ કરવું નહીં, ઉદાહરણ તરીકે, મેમરી, CPU અથવા એવું કંઈક, પરંતુ વર્કલોડનું વિશ્લેષણ કરવું અને શક્ય તેટલું થ્રુપુટ સુધારવાનો પ્રયાસ કરવાનો છે જેથી સારા પ્રોગ્રામરોએ તેને બનાવેલ લોડ અમારા વપરાશકર્તાઓ સહિત અમારા માટે.

તે શું છે તે સમજાવવા માટે અહીં એક ચિત્ર છે. ત્યાં એક Linux OS બફર છે અને ત્યાં વહેંચાયેલ મેમરી છે અને 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 પર સામાન્ય રીતે તે મોડ્યુલમાં જ ઓછી મેમરી હોય છે. અને બધી મેમરી જે સર્વિસ કરવામાં આવે છે તે આ ઇન્ટરકનેક્ટ્સમાંથી પસાર થાય છે. તે ધીમી અને ઉદાસી બહાર વળે છે. અને તમારું પ્રોસેસર જે આ નોડને સેવા આપે છે તે સતત ઓવરલોડ થાય છે. અને આ મેમરીનો એક્સેસ ટાઇમ ખરાબ, ધીમો છે. જો તમે ડેટાબેઝ માટે આનો ઉપયોગ કરી રહ્યાં હોવ તો આ એવી પરિસ્થિતિ છે જે તમે ઇચ્છતા નથી.

તેથી, ડેટાબેઝ માટે વધુ સાચો વિકલ્પ એ છે કે લિનક્સ ઓપરેટિંગ સિસ્ટમને ખબર ન પડે કે ત્યાં શું ચાલી રહ્યું છે. જેથી તે મેમરીને ઍક્સેસ કરે છે જેમ તે કરે છે.

તે શા માટે છે? એવું લાગે છે કે તે બીજી રીતે હોવું જોઈએ. આ એક સરળ કારણોસર થાય છે: અમને પૃષ્ઠ કેશ માટે ઘણી બધી મેમરીની જરૂર છે - દસ, સેંકડો ગીગાબાઇટ્સ.

અને જો આપણે આ બધું ફાળવી દઈએ અને આપણો ડેટા ત્યાં કેશ કરીએ, તો કેશનો ઉપયોગ કરવાથી મળતો ફાયદો મેમરીમાં આવી મુશ્કેલ એક્સેસના ફાયદા કરતાં નોંધપાત્ર રીતે વધારે હશે. અને આ રીતે અમે NUMA નો ઉપયોગ કરીને મેમરીને વધુ અસરકારક રીતે એક્સેસ કરીશું તે હકીકતની સરખામણીમાં અમને અજોડ ફાયદો થશે.

તેથી, આ ક્ષણે અહીં બે અભિગમો છે, જ્યાં સુધી ઉજ્જવળ ભવિષ્ય ન આવે ત્યાં સુધી, અને ડેટાબેઝ પોતે જ એ સમજવામાં સક્ષમ નથી કે તે કયા CPU પર ચાલી રહ્યું છે અને તેને ક્યાંથી કંઈક ખેંચવાની જરૂર છે.

તેથી, NUMA ને સંપૂર્ણ રીતે અક્ષમ કરવાનો સાચો અભિગમ છે, ઉદાહરણ તરીકે, રીબૂટ કરતી વખતે. મોટા ભાગના કિસ્સાઓમાં, જીત એટલી તીવ્રતાના ઓર્ડરની હોય છે કે જે વધુ સારું છે તે પ્રશ્ન જ ઊભો થતો નથી.

બીજો વિકલ્પ છે. અમે તેનો ઉપયોગ પહેલા કરતા વધુ વખત કરીએ છીએ, કારણ કે જ્યારે કોઈ ક્લાયંટ અમારી પાસે સપોર્ટ માટે આવે છે, ત્યારે સર્વર રીબૂટ કરવું તેના માટે મોટી વાત છે. તેનો ત્યાં બિઝનેસ છે. અને તેઓ NUMA ના કારણે સમસ્યાઓ અનુભવે છે. તેથી, અમે તેને રીબૂટ કરતાં ઓછી આક્રમક રીતે અક્ષમ કરવાનો પ્રયાસ કરીએ છીએ, પરંતુ તે અક્ષમ છે કે નહીં તે તપાસવા માટે સાવચેત રહો. કારણ કે, અનુભવ બતાવે છે તેમ, તે સારું છે કે અમે પેરેન્ટ PostgreSQL પ્રક્રિયા પર NUMA ને અક્ષમ કરીએ, પરંતુ તે કામ કરશે તે બિલકુલ જરૂરી નથી. અમારે તપાસ કરવાની અને જોવાની જરૂર છે કે તેણી ખરેખર બંધ થઈ ગઈ છે.

રોબર્ટ હાસ દ્વારા એક સારી પોસ્ટ છે. આ PostgreSQL કમિટર્સમાંથી એક છે. તમામ નિમ્ન-સ્તરના ગિબ્લેટ્સના મુખ્ય વિકાસકર્તાઓમાંના એક. અને જો તમે આ પોસ્ટની લિંક્સને અનુસરો છો, તો તેઓ કેવી રીતે NUMA એ લોકો માટે જીવન મુશ્કેલ બનાવ્યું તે વિશેની ઘણી રંગીન વાર્તાઓનું વર્ણન કરે છે. જુઓ, અમારા ડેટાબેઝને સારી રીતે કામ કરવા માટે સર્વર પર શું ગોઠવવાની જરૂર છે તેની સિસ્ટમ એડમિનિસ્ટ્રેટર ચેકલિસ્ટનો અભ્યાસ કરો. આ સેટિંગ્સને લખી અને તપાસવાની જરૂર છે, કારણ કે અન્યથા તે ખૂબ સારું રહેશે નહીં.

મહેરબાની કરીને નોંધ કરો કે આ બધી સેટિંગ્સને લાગુ પડે છે જેના વિશે હું વાત કરીશ. પરંતુ સામાન્ય રીતે ડેટાબેઝ દોષ સહિષ્ણુતા માટે માસ્ટર-સ્લેવ મોડમાં એકત્રિત કરવામાં આવે છે. ગુલામ પર આ સેટિંગ્સ કરવાનું ભૂલશો નહીં કારણ કે એક દિવસ તમારો અકસ્માત થશે અને તમે ગુલામ પર સ્વિચ કરશો અને તે માસ્ટર બની જશે.

કટોકટીની પરિસ્થિતિમાં, જ્યારે બધું ખૂબ જ ખરાબ હોય, તમારો ફોન સતત વાગી રહ્યો હોય અને તમારા બોસ મોટી લાકડી લઈને દોડી આવે, ત્યારે તમારી પાસે તપાસ કરવા વિશે વિચારવાનો સમય નહીં હોય. અને પરિણામો તદ્દન વિનાશક હોઈ શકે છે.

આગળનો મુદ્દો વિશાળ પૃષ્ઠો છે. વિશાળ પૃષ્ઠોનું અલગથી પરીક્ષણ કરવું મુશ્કેલ છે, અને આમ કરવાનો કોઈ અર્થ નથી, જો કે ત્યાં બેન્ચમાર્ક્સ છે જે આ કરી શકે છે. તેઓ Google માટે સરળ છે.

શું વાત છે? તમારી પાસે ઘણી બધી RAM સાથે ખૂબ ખર્ચાળ સર્વર નથી, ઉદાહરણ તરીકે, 30 GB થી વધુ. તમે વિશાળ પૃષ્ઠોનો ઉપયોગ કરતા નથી. આનો અર્થ એ છે કે મેમરી વપરાશના સંદર્ભમાં તમારી પાસે ચોક્કસપણે ઓવરહેડ છે. અને આ ઓવરહેડ સૌથી સુખદથી દૂર છે.

તે શા માટે છે? તો શું થઈ રહ્યું છે? ઓપરેટિંગ સિસ્ટમ મેમરીને નાના ટુકડાઓમાં ફાળવે છે. તે ખૂબ અનુકૂળ છે, તે ઐતિહાસિક રીતે કેવી રીતે થયું છે. અને જો આપણે વિગતમાં જઈએ, તો OS એ વર્ચ્યુઅલ સરનામાંઓને ભૌતિકમાં અનુવાદિત કરવું આવશ્યક છે. અને આ પ્રક્રિયા સૌથી સરળ નથી, તેથી OS આ ઓપરેશનના પરિણામને ટ્રાન્સલેશન લુકસાઇડ બફર (TLB) માં કેશ કરે છે.

અને TLB એક કેશ હોવાથી, આ પરિસ્થિતિમાં કેશમાં રહેલી તમામ સમસ્યાઓ ઊભી થાય છે. સૌપ્રથમ, જો તમારી પાસે ઘણી બધી RAM હોય અને તે તમામ નાના ટુકડાઓમાં ફાળવવામાં આવે, તો આ બફર ખૂબ જ વિશાળ બની જાય છે. અને જો કેશ મોટી હોય, તો તેના દ્વારા શોધવાનું ધીમું છે. ઓવરહેડ સ્વસ્થ છે અને તે પોતે જ જગ્યા લે છે, એટલે કે RAM નો ઉપયોગ કંઈક અયોગ્ય છે. આ સમયે.

બે - આવી પરિસ્થિતિમાં જેટલી વધુ કેશ વધે છે, તેટલી વધુ શક્યતા છે કે તમારી પાસે કેશ ચૂકી જશે. અને આ કેશની કાર્યક્ષમતા ઝડપથી ઘટે છે કારણ કે તેનું કદ વધે છે. તેથી, ઑપરેટિંગ સિસ્ટમ્સ એક સરળ અભિગમ સાથે આવી. તે Linux માં લાંબા સમયથી ઉપયોગમાં લેવાય છે. તે આટલા લાંબા સમય પહેલા ફ્રીબીએસડીમાં દેખાયું હતું. પરંતુ અમે Linux વિશે વાત કરી રહ્યા છીએ. આ વિશાળ પૃષ્ઠો છે.

અને અહીં એ નોંધવું જોઈએ કે વિશાળ પૃષ્ઠો, એક વિચાર તરીકે, શરૂઆતમાં સમુદાયો દ્વારા દબાણ કરવામાં આવ્યું હતું જેમાં Oracle અને IBMનો સમાવેશ થતો હતો, એટલે કે ડેટાબેઝ ઉત્પાદકોએ ભારપૂર્વક વિચાર્યું હતું કે આ ડેટાબેઝ માટે પણ ઉપયોગી થશે.

અને આને PostgreSQL સાથે મિત્રતા કેવી રીતે બનાવી શકાય? પ્રથમ, Linux કર્નલમાં વિશાળ પૃષ્ઠો સક્ષમ હોવા જોઈએ.

બીજું, તેઓ સ્પષ્ટપણે sysctl પરિમાણ દ્વારા નિર્દિષ્ટ હોવા જોઈએ - ત્યાં કેટલા છે. અહીંના નંબરો કેટલાક જૂના સર્વરમાંથી છે. તમે ગણતરી કરી શકો છો કે તમારી પાસે કેટલા શેર બફર્સ છે જેથી વિશાળ પૃષ્ઠો ત્યાં ફિટ થઈ શકે.

અને જો તમારું આખું સર્વર PostgreSQL ને સમર્પિત છે, તો એક સારો પ્રારંભિક બિંદુ ક્યાં તો 25% RAM ને વહેંચાયેલ બફર્સ માટે ફાળવવાનું છે, અથવા 75% જો તમને ખાતરી છે કે તમારો ડેટાબેઝ ચોક્કસપણે આ 75% માં ફિટ થશે. પ્રારંભિક બિંદુ એક. અને ધ્યાનમાં લો, જો તમારી પાસે 256 જીબી રેમ છે, તો તે મુજબ, તમારી પાસે 64 જીબી મોટા બફર્સ હશે. કેટલાક માર્જિન સાથે અંદાજે ગણતરી કરો - આ આંકડો શું સેટ કરવો જોઈએ.

સંસ્કરણ 9.2 પહેલા (જો મારી ભૂલ ન હોય તો, સંસ્કરણ 8.2 થી), તૃતીય-પક્ષ લાઇબ્રેરીનો ઉપયોગ કરીને પોસ્ટગ્રેએસક્યુએલને વિશાળ પૃષ્ઠો સાથે કનેક્ટ કરવું શક્ય હતું. અને આ હંમેશા કરવું જોઈએ. પ્રથમ, તમારે વિશાળ પૃષ્ઠોને યોગ્ય રીતે ફાળવવામાં સક્ષમ થવા માટે કર્નલની જરૂર છે. અને, બીજું, જેથી તેમની સાથે કામ કરતી એપ્લિકેશન તેનો ઉપયોગ કરી શકે. તે ફક્ત તે રીતે ઉપયોગમાં લેવાશે નહીં. PostgreSQL એ સિસ્ટમ 5 શૈલીમાં મેમરી ફાળવી હોવાથી, આ libhugetlbfs નો ઉપયોગ કરીને કરી શકાય છે - આ પુસ્તકાલયનું પૂરું નામ છે.

9.3 માં, મેમરી સાથે કામ કરતી વખતે PostgreSQL કામગીરી બહેતર બનાવવામાં આવી હતી અને સિસ્ટમ 5 મેમરી ફાળવણી પદ્ધતિ છોડી દેવામાં આવી હતી. દરેક વ્યક્તિ ખૂબ જ ખુશ હતો, કારણ કે અન્યથા તમે એક મશીન પર બે PostgreSQL દાખલાઓ ચલાવવાનો પ્રયાસ કરો છો, અને તે કહે છે કે મારી પાસે પૂરતી વહેંચાયેલ મેમરી નથી. અને તે કહે છે કે sysctl ને સુધારવાની જરૂર છે. અને એવી sysctl છે કે તમારે હજી પણ રીબૂટ કરવાની જરૂર છે, વગેરે. સામાન્ય રીતે, દરેક જણ ખુશ હતા. પરંતુ mmap મેમરી ફાળવણીએ વિશાળ પૃષ્ઠોનો ઉપયોગ તોડ્યો. અમારા મોટાભાગના ગ્રાહકો મોટા શેર કરેલ બફરનો ઉપયોગ કરે છે. અને અમે ભારપૂર્વક ભલામણ કરી છે કે 9.3 પર સ્વિચ ન કરો, કારણ કે ત્યાં ઓવરહેડ સારી ટકાવારીમાં ગણવામાં આવે છે.

પરંતુ સમુદાયે આ સમસ્યા પર ધ્યાન આપ્યું અને 9.4 માં તેઓએ આ ઇવેન્ટને ખૂબ સારી રીતે ફરીથી કાર્ય કર્યું. અને 9.4 માં postgresql.conf માં પેરામીટર દેખાયું જેમાં તમે ચાલુ અથવા બંધ કરવાનો પ્રયાસ કરી શકો છો.

પ્રયાસ એ સૌથી સલામત વિકલ્પ છે. જ્યારે PostgreSQL શરૂ થાય છે, જ્યારે તે વહેંચાયેલ મેમરી ફાળવે છે, ત્યારે તે વિશાળ પૃષ્ઠોમાંથી આ મેમરીને ખેંચવાનો પ્રયાસ કરે છે. અને જો તે કામ કરતું નથી, તો તે સામાન્ય પસંદગી પર પાછા ફરે છે. અને જો તમારી પાસે ફ્રીબીએસડી અથવા સોલારિસ છે, તો તમે પ્રયાસ કરી શકો છો, તે હંમેશા સલામત છે.

જો ચાલુ હોય, તો જો તે વિશાળ પૃષ્ઠોમાંથી પસંદ ન કરી શકે તો તે ફક્ત શરૂ થતું નથી. અહીં તે પહેલેથી જ છે કે કોણ અને શું સારું છે. પરંતુ જો તમે પ્રયાસ કર્યો હોય, તો પછી તપાસો કે તમારી પાસે ખરેખર તમને જે જોઈએ છે તે પ્રકાશિત કરવામાં આવ્યું છે, કારણ કે ભૂલ માટે ઘણી જગ્યા છે. હાલમાં આ કાર્યક્ષમતા ફક્ત Linux પર જ કામ કરે છે.

આપણે આગળ જતા પહેલા એક વધુ નાની નોંધ. પારદર્શક વિશાળ પૃષ્ઠો હજુ સુધી PostgreSQL વિશે નથી. તે સામાન્ય રીતે તેનો ઉપયોગ કરી શકતો નથી. અને આવા વર્કલોડ માટે પારદર્શક વિશાળ પૃષ્ઠો સાથે, જ્યારે વહેંચાયેલ મેમરીના મોટા ભાગની જરૂર હોય, ત્યારે લાભો ફક્ત ખૂબ મોટા વોલ્યુમો સાથે આવે છે. જો તમારી પાસે ટેરાબાઇટ્સ મેમરી હોય તો આ કામમાં આવી શકે છે. જો આપણે વધુ રોજિંદા એપ્લિકેશન વિશે વાત કરી રહ્યા છીએ, જ્યારે તમારી પાસે તમારા મશીન પર 32, 64, 128, 256 GB મેમરી હોય, તો સામાન્ય વિશાળ પૃષ્ઠો બરાબર છે, અને અમે ફક્ત પારદર્શકને અક્ષમ કરીએ છીએ.

અને મેમરી વિશેની છેલ્લી વસ્તુ સીધી રીતે ફ્રુટ સાથે સંબંધિત નથી, તે ખરેખર તમારા જીવનને બરબાદ કરી શકે છે. સર્વર સતત અદલાબદલી થઈ રહ્યું છે તે હકીકત દ્વારા તમામ થ્રુપુટને ખૂબ અસર થશે.

અને આ ઘણી રીતે ખૂબ જ અપ્રિય હશે. અને મુખ્ય સમસ્યા એ છે કે આધુનિક કર્નલો જૂના Linux કર્નલ કરતાં સહેજ અલગ રીતે વર્તે છે. અને આ બાબત આગળ વધવા માટે ખૂબ જ અપ્રિય છે, કારણ કે જ્યારે આપણે સ્વેપ સાથેના અમુક પ્રકારના કામ વિશે વાત કરીએ છીએ, ત્યારે તે OOM-કિલરના અકાળે આગમન સાથે સમાપ્ત થાય છે. અને OOM-કિલર, જે સમયસર ન પહોંચ્યું અને PostgreSQL છોડી દીધું, તે અપ્રિય છે. દરેક વ્યક્તિ આ વિશે જાણશે, એટલે કે, છેલ્લા વપરાશકર્તા સુધી.

શું થઈ રહ્યું છે? તમારી પાસે ત્યાં મોટી માત્રામાં RAM છે, બધું સારી રીતે કાર્ય કરે છે. પરંતુ કેટલાક કારણોસર સર્વર સ્વેપમાં અટકી જાય છે અને તેના કારણે ધીમી પડી જાય છે. એવું લાગે છે કે ત્યાં ઘણી બધી મેમરી છે, પરંતુ આવું થાય છે.

અગાઉ, અમે vm.swappiness ને શૂન્ય પર સેટ કરવાની સલાહ આપી હતી, એટલે કે સ્વેપને અક્ષમ કરો. પહેલાં, એવું લાગતું હતું કે 32 GB ની RAM અને અનુરૂપ વહેંચાયેલ બફર્સ મોટી રકમ છે. સ્વેપનો મુખ્ય હેતુ એ છે કે જો આપણે પડી જઈએ તો પોપડાને ફેંકવાની જગ્યા હોય. અને તે લાંબા સમય સુધી ખાસ પરિપૂર્ણ ન હતી. અને પછી તમે આ પોપડા સાથે શું કરવા જઈ રહ્યા છો? આ એક કાર્ય છે જ્યાં તે ખૂબ જ સ્પષ્ટ નથી કે શા માટે સ્વેપની જરૂર છે, ખાસ કરીને આવા કદના.

પરંતુ વધુ આધુનિક, એટલે કે, કર્નલના ત્રીજા સંસ્કરણોમાં, વર્તન બદલાઈ ગયું છે. અને જો તમે સ્વેપને શૂન્ય પર સેટ કરો છો, એટલે કે તેને બંધ કરો છો, તો વહેલા કે પછી, થોડીક રેમ બાકી હોય તો પણ, સૌથી વધુ સઘન ગ્રાહકોને મારવા માટે OOM કિલર તમારી પાસે આવશે. કારણ કે તે વિચારશે કે આવા કામના બોજ સાથે આપણી પાસે હજી થોડોક બાકી છે અને આપણે બહાર નીકળી જઈશું, એટલે કે, સિસ્ટમની પ્રક્રિયાને ખીલવવા માટે નહીં, પરંતુ કંઈક ઓછું મહત્ત્વપૂર્ણ બનાવવા માટે. આ ઓછું મહત્વનું શેર કરેલ મેમરીના સઘન ઉપભોક્તા હશે, એટલે કે પોસ્ટમાસ્ટર. અને તે પછી તે સારું રહેશે જો આધારને પુનઃસ્થાપિત કરવાની જરૂર નથી.

તેથી, હવે ડિફોલ્ટ, જ્યાં સુધી મને યાદ છે, મોટા ભાગના વિતરણો ક્યાંક 6 ની આસપાસ છે, એટલે કે કેટલી મેમરી બાકી છે તેના આધારે તમારે સ્વેપનો ઉપયોગ કયા સમયે શરૂ કરવો જોઈએ. અમે હવે vm.swappiness = 1 સુયોજિત કરવાની ભલામણ કરીએ છીએ, કારણ કે આ વ્યવહારીક રીતે તેને બંધ કરે છે, પરંતુ OOM-કિલર જેવી જ અસરો આપતું નથી કે જે અણધારી રીતે આવીને સમગ્ર વસ્તુને મારી નાખે છે.

આગળ શું છે? જ્યારે આપણે ડેટાબેસેસના પ્રદર્શન વિશે વાત કરીએ છીએ અને ધીમે ધીમે ડિસ્ક તરફ આગળ વધીએ છીએ, ત્યારે દરેક વ્યક્તિ તેમના માથાને પકડવાનું શરૂ કરે છે. કારણ કે ડિસ્ક ધીમી છે અને યાદશક્તિ ઝડપી છે એ સત્ય બાળપણથી દરેકને પરિચિત છે. અને દરેક વ્યક્તિ જાણે છે કે ડેટાબેઝમાં ડિસ્ક પ્રદર્શન સમસ્યાઓ હશે.

ચેકપોઇન્ટ સ્પાઇક્સ સાથે સંકળાયેલી મુખ્ય PostgreSQL કામગીરી સમસ્યા ઊભી થતી નથી કારણ કે ડિસ્ક ધીમી છે. આ મોટે ભાગે એ હકીકતને કારણે છે કે મેમરી અને ડિસ્ક બેન્ડવિડ્થ સંતુલિત નથી. જો કે, તેઓ વિવિધ સ્થળોએ સંતુલિત હોઈ શકતા નથી. PostgreSQL રૂપરેખાંકિત થયેલ નથી, OS રૂપરેખાંકિત થયેલ નથી, હાર્ડવેર ગોઠવેલ નથી અને હાર્ડવેર ખોટું છે. અને આ સમસ્યા ત્યારે જ થતી નથી જ્યારે બધું જોઈએ તે પ્રમાણે થાય, એટલે કે ક્યાં તો કોઈ લોડ નથી, અથવા સેટિંગ્સ અને હાર્ડવેર સારી રીતે પસંદ કરેલ છે.

તે શું છે અને તે શું દેખાય છે? સામાન્ય રીતે જે લોકો 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 અગ્રતા એ આખી વસ્તુને ડિસ્ક પર લખવાની છે, કારણ કે પાવર નિષ્ફળ જશે અને બધું આપણા માટે ખરાબ થશે. અમે આ ડેટા ગુમાવીશું, ઉદાહરણ તરીકે.

યુક્તિ શું છે? યુક્તિ એ છે કે આધુનિક વિશ્વમાં આ પરિમાણો મશીન પરની કુલ રેમના 20 અને 10% છે, તે તમારી પાસેની કોઈપણ ડિસ્ક સિસ્ટમના થ્રુપુટની દ્રષ્ટિએ એકદમ ભયંકર છે.

કલ્પના કરો કે તમારી પાસે 128 GB RAM છે. 12,8 GB તમારી ડિસ્ક સિસ્ટમમાં આવે છે. અને તમારી પાસે ગમે તેટલી કેશ હોય, તમારી પાસે ગમે તે અરે હોય, તે આટલા લાંબા સમય સુધી ચાલશે નહીં.

તેથી, અમે ભલામણ કરીએ છીએ કે તમે તમારા RAID નિયંત્રકની ક્ષમતાઓના આધારે આ નંબરોને તરત જ સમાયોજિત કરો. મેં તરત જ અહીં એવા નિયંત્રક માટે ભલામણ કરી છે કે જેની પાસે 512 MB કેશ છે.

બધું ખૂબ જ સરળ માનવામાં આવે છે. તમે બાઈટમાં vm.dirty_background મૂકી શકો છો. અને આ સેટિંગ્સ પાછલા બેને રદ કરે છે. કાં તો ગુણોત્તર ડિફૉલ્ટ રૂપે છે, અથવા તે બાઇટ્સ સાથે સક્રિય છે, પછી તે બાઇટ સાથે કામ કરશે. પરંતુ હું ડીબીએ કન્સલ્ટન્ટ છું અને જુદા જુદા ગ્રાહકો સાથે કામ કરું છું, તેથી હું સ્ટ્રો દોરવાનો પ્રયત્ન કરું છું અને તેથી, જો બાઈટમાં હોય, તો પછી બાઈટમાં. કોઈએ કોઈ ગેરેંટી આપી ન હતી કે સારો એડમિન સર્વરમાં વધુ મેમરી ઉમેરશે નહીં, તેને રીબૂટ કરશે નહીં અને આકૃતિ સમાન રહેશે. ફક્ત આ સંખ્યાઓની ગણતરી કરો જેથી બધું ગેરંટી સાથે ત્યાં બંધબેસે.

જો તમે ફિટ ન થાઓ તો શું થશે? મેં લખ્યું છે કે કોઈપણ ફ્લશિંગ અસરકારક રીતે બંધ થાય છે, પરંતુ વાસ્તવમાં આ ભાષણની આકૃતિ છે. ઑપરેટિંગ સિસ્ટમમાં એક મોટી સમસ્યા છે - તેમાં ઘણાં ગંદા પૃષ્ઠો છે, તેથી તમારા ક્લાયન્ટ્સ જે IO જનરેટ કરે છે તે અસરકારક રીતે બંધ થઈ ગયું છે, એટલે કે એપ્લિકેશન ડેટાબેઝ પર sql ક્વેરી મોકલવા આવી છે, તે રાહ જોઈ રહી છે. તેમાં કોઈપણ ઇનપુટ/આઉટપુટ સૌથી નીચી પ્રાધાન્યતા ધરાવે છે, કારણ કે ડેટાબેઝ ચેકપોઇન્ટ દ્વારા કબજે કરવામાં આવે છે. અને તે ક્યારે સમાપ્ત કરશે તે સંપૂર્ણપણે અસ્પષ્ટ છે. અને જ્યારે તમે નોન-બેકગ્રાઉન્ડ ફ્લશિંગ હાંસલ કર્યું હોય, ત્યારે તેનો અર્થ એ છે કે તમારા બધા IO તેના દ્વારા કબજે કરવામાં આવ્યા છે. અને જ્યાં સુધી તે સમાપ્ત ન થાય ત્યાં સુધી તમે કંઈ કરશો નહીં.

અહીં વધુ બે મહત્વપૂર્ણ મુદ્દાઓ છે જે આ અહેવાલના અવકાશની બહાર છે. આ સેટિંગ્સ postgresql.conf માં સેટિંગ્સ સાથે મેળ ખાતી હોવી જોઈએ, એટલે કે ચેકપોઇન્ટ સેટિંગ્સ. અને તમારી ડિસ્ક સિસ્ટમ પર્યાપ્ત રીતે ગોઠવેલી હોવી જોઈએ. જો તમારી પાસે RAID પર કેશ છે, તો તેમાં બેટરી હોવી આવશ્યક છે. લોકો બેટરી વગર સારી કેશ સાથે RAID ખરીદે છે. જો તમારી પાસે RAID માં SSD છે, તો તે સર્વર હોવા જોઈએ, ત્યાં કેપેસિટર્સ હોવા જોઈએ. અહીં વિગતવાર ચેકલિસ્ટ છે. આ લિંકમાં પોસ્ટગ્રેએસક્યુએલમાં પ્રદર્શન ડિસ્કને કેવી રીતે ગોઠવવી તે અંગેનો મારો અહેવાલ છે. ત્યાં આ તમામ ચેકલિસ્ટ છે.

બીજું શું જીવનને ખૂબ મુશ્કેલ બનાવી શકે છે? આ બે પરિમાણો છે. તેઓ પ્રમાણમાં નવા છે. મૂળભૂત રીતે, તેઓ વિવિધ કાર્યક્રમોમાં સમાવી શકાય છે. અને જો તેઓ ખોટી રીતે ચાલુ કરવામાં આવે તો તેઓ જીવનને એટલું જ મુશ્કેલ બનાવી શકે છે.

ત્યાં બે પ્રમાણમાં નવી વસ્તુઓ છે. તેઓ પહેલાથી જ ત્રીજા કોરોમાં દેખાયા છે. આ નેનોસેકન્ડમાં sched_migration_cost અને sched_autogroup_enabled છે, જે મૂળભૂત રીતે એક છે.

અને તેઓ તમારા જીવનને કેવી રીતે બગાડે છે? શેડ_માઇગ્રેશન_કોસ્ટ શું છે? Linux પર, શેડ્યૂલર પ્રક્રિયાને એક CPU થી બીજામાં સ્થાનાંતરિત કરી શકે છે. અને PostgreSQL માટે, જે ક્વેરીઝ એક્ઝિક્યુટ કરે છે, બીજા CPU પર સ્થળાંતર કરવું એ સંપૂર્ણપણે અસ્પષ્ટ છે. ઑપરેટિંગ સિસ્ટમના દૃષ્ટિકોણથી, જ્યારે તમે ઓપનઑફિસ અને ટર્મિનલ વચ્ચે વિન્ડોઝ સ્વિચ કરો છો, ત્યારે આ સારું હોઈ શકે છે, પરંતુ ડેટાબેઝ માટે આ ખૂબ જ ખરાબ છે. તેથી, એક વાજબી નીતિ છે migration_cost ને અમુક મોટા મૂલ્ય, ઓછામાં ઓછા કેટલાક હજાર નેનોસેકન્ડ્સ પર સેટ કરવાની.

શેડ્યૂલર માટે આનો અર્થ શું થશે? તે ધ્યાનમાં લેવામાં આવશે કે આ સમય દરમિયાન પ્રક્રિયા હજુ પણ ગરમ છે. એટલે કે, જો તમારી પાસે લાંબા સમયથી ચાલતો વ્યવહાર છે જે લાંબા સમયથી કંઈક કરી રહ્યો છે, તો શેડ્યૂલર આ સમજી જશે. તે માની લેશે કે જ્યાં સુધી આ સમય સમાપ્ત ન થાય ત્યાં સુધી, આ પ્રક્રિયાને ક્યાંય સ્થાનાંતરિત કરવાની જરૂર નથી. જો તે જ સમયે પ્રક્રિયા કંઈક કરે છે, તો પછી તે ક્યાંય સ્થાનાંતરિત થશે નહીં, તે શાંતિથી તેને ફાળવેલ CPU પર કામ કરશે. અને પરિણામ ઉત્તમ છે.

બીજો મુદ્દો ઓટોગ્રુપ છે. વિશિષ્ટ વર્કલોડ માટે એક સારો વિચાર છે જે આધુનિક ડેટાબેસેસ સાથે સંબંધિત નથી - આ વર્ચ્યુઅલ ટર્મિનલ દ્વારા પ્રક્રિયાઓને જૂથબદ્ધ કરવાનો છે કે જ્યાંથી તેઓ લોન્ચ કરવામાં આવે છે. કેટલાક કાર્યો માટે આ અનુકૂળ છે. વ્યવહારમાં, PostgreSQL એ પ્રીફોર્ક સાથેની મલ્ટિ-પ્રોસેસ સિસ્ટમ છે જે સિંગલ ટર્મિનલથી ચાલે છે. તમારી પાસે લૉક રાઇટર, ચેકપોઇન્ટ છે અને તમારી તમામ ક્લાયન્ટ વિનંતીઓને એક શેડ્યૂલરમાં, CPU દીઠ જૂથબદ્ધ કરવામાં આવશે. અને તેઓ એકબીજા સાથે દખલ કરવા અને તેને લાંબા સમય સુધી વ્યસ્ત રાખવા માટે, તેના મુક્ત થવા માટે એકસાથે રાહ જોશે. આ એક વાર્તા છે જે આવા ભારના કિસ્સામાં સંપૂર્ણપણે બિનજરૂરી છે અને તેથી તેને બંધ કરવાની જરૂર છે.

મારા સાથીદાર એલેક્સી લેસોવ્સ્કીએ એક સાદી pgbench સાથે પરીક્ષણો કર્યા, જ્યાં તેણે migration_cost ને તીવ્રતાના ક્રમમાં વધાર્યું અને ઑટોગ્રુપ બંધ કર્યું. ખરાબ હાર્ડવેર પર તફાવત લગભગ 10% હતો. પોસ્ટગ્રેસ મેઇલિંગ લિસ્ટ પર ચર્ચા છે જ્યાં લોકો ક્વેરી સ્પીડમાં સમાન ફેરફારોના પરિણામો આપે છે 50% પ્રભાવિત. આવી ઘણી બધી વાર્તાઓ છે.

અને છેલ્લે, પાવર સેવિંગ પોલિસી વિશે. સારી વાત એ છે કે લિનક્સ હવે લેપટોપ પર વાપરી શકાય છે. અને તે માનવામાં આવે છે કે બેટરીનો સારી રીતે ઉપયોગ કરશે. પરંતુ અચાનક તે તારણ આપે છે કે આ સર્વર પર પણ થઈ શકે છે.

તદુપરાંત, જો તમે કોઈ હોસ્ટર પાસેથી સર્વર ભાડે લો છો, તો પછી "સારા" હોસ્ટર્સ તમારી પાસે વધુ સારું પ્રદર્શન છે તેની કાળજી લેતા નથી. તેમનું કાર્ય એ સુનિશ્ચિત કરવાનું છે કે તેમના લોખંડનો શક્ય તેટલો કાર્યક્ષમ ઉપયોગ થાય છે. તેથી, મૂળભૂત રીતે તેઓ ઓપરેટિંગ સિસ્ટમ પર લેપટોપ પાવર સેવિંગ મોડને સક્ષમ કરી શકે છે.

જો તમે ભારે ભાર હેઠળ ડેટાબેઝ ધરાવતા સર્વર પર આ સામગ્રીનો ઉપયોગ કરો છો, તો તમારી પસંદગી acpi_cpufreq + permormance છે. ઓનડિમાન્ડ સાથે પણ સમસ્યાઓ હશે.

Intel_pstate એ થોડો અલગ ડ્રાઈવર છે. અને હવે આને પ્રાધાન્ય આપવામાં આવે છે, કારણ કે તે પછીનું છે અને વધુ સારું કામ કરે છે.

અને, તે મુજબ, ગવર્નર માત્ર કામગીરી છે. ઓન્ડમાન્ડ, પાવરસેવ અને બીજું બધું તમારા વિશે નથી.

જો તમે પાવરસેવને સક્ષમ કરો છો, તો પોસ્ટગ્રેએસક્યુએલના સ્પષ્ટીકરણ વિશ્લેષણના પરિણામો ઘણા બધા ઓર્ડરથી અલગ હોઈ શકે છે, કારણ કે વ્યવહારીક રીતે તમારા ડેટાબેઝ હેઠળનું CPU સંપૂર્ણપણે અણધારી રીતે ચાલતું હશે.

આ આઇટમ્સ મૂળભૂત રીતે શામેલ હોઈ શકે છે. તેઓએ તેને ડિફોલ્ટ રૂપે ચાલુ કર્યું છે કે કેમ તે જોવા માટે કાળજીપૂર્વક જુઓ. આ ખરેખર મોટી સમસ્યા બની શકે છે.

અને અંતે, હું અમારી PosgreSQL-કન્સલ્ટિંગ DBA ટીમના લોકોનો આભાર કહેવા માંગુ છું, જેમ કે મેક્સ બોગુક અને એલેક્સી લેસોવસ્કી, જેઓ દરરોજ આ બાબતે આગળ વધી રહ્યા છે. અને અમે અમારા ગ્રાહકો માટે અમે જે કરી શકીએ તે શ્રેષ્ઠ કરવાનો પ્રયાસ કરીએ છીએ જેથી તે બધું તેમના માટે કાર્ય કરે. તે ઉડ્ડયન સુરક્ષા સૂચનાઓ જેવું છે. અહીં બધું લોહીમાં લખેલું છે. આ દરેક બદામ અમુક પ્રકારની સમસ્યાની પ્રક્રિયામાં જોવા મળે છે. હું તેમને તમારી સાથે શેર કરવામાં ખુશ છું.

પ્રશ્નો

આભાર! જો, ઉદાહરણ તરીકે, કોઈ કંપની નાણાં બચાવવા અને ડેટાબેઝ અને એપ્લિકેશન લોજિકને એક સર્વર પર મૂકવા માંગે છે, અથવા જો કંપની માઇક્રોસર્વિસ આર્કિટેક્ચરના ફેશનેબલ વલણને અનુસરે છે, જેમાં પોસ્ટગ્રેએસક્યુએલ કન્ટેનરમાં ચાલે છે. યુક્તિ શું છે? Sysctl વૈશ્વિક સ્તરે સમગ્ર કર્નલને અસર કરશે. મેં sysctls ને કોઈક રીતે વર્ચ્યુઅલાઈઝ કરવામાં આવ્યું હોવાનું સાંભળ્યું નથી જેથી તેઓ કન્ટેનર પર અલગથી કામ કરે. ત્યાં માત્ર એક cgroup છે અને ત્યાં નિયંત્રણનો માત્ર એક ભાગ છે. તમે આ સાથે કેવી રીતે જીવી શકો? અથવા જો તમારે પરફોર્મન્સ જોઈતું હોય, તો પછી અલગ હાર્ડવેર સર્વર પર PostgreSQL ચલાવો અને તેને ટ્યુન કરો?

અમે તમારા પ્રશ્નનો લગભગ ત્રણ રીતે જવાબ આપ્યો છે. જો આપણે હાર્ડવેર સર્વર વિશે વાત કરી રહ્યા નથી જે ટ્યુન કરી શકાય છે, વગેરે, તો પછી આરામ કરો, આ સેટિંગ્સ વિના બધું સારું કામ કરશે. જો તમારી પાસે આટલો ભાર છે કે તમારે આ સેટિંગ્સ કરવાની જરૂર છે, તો પછી તમે આ સેટિંગ્સ કરતાં પહેલાં આયર્ન સર્વર પર આવશો.

શું સમસ્યા છે? જો આ વર્ચ્યુઅલ મશીન છે, તો સંભવતઃ તમને ઘણી સમસ્યાઓ હશે, ઉદાહરણ તરીકે, એ હકીકત સાથે કે મોટાભાગના વર્ચ્યુઅલ મશીનો પર ડિસ્કની લેટન્સી તદ્દન અસંગત છે. જો ડિસ્ક થ્રુપુટ સારું હોય તો પણ, એક નિષ્ફળ I/O ટ્રાન્ઝેક્શન જે ચેકપોઇન્ટના સમયે અથવા WAL ને લખવાના સમયે બનેલા સરેરાશ થ્રુપુટને મોટા પ્રમાણમાં અસર કરતું નથી, તો ડેટાબેઝ આનાથી મોટા પ્રમાણમાં પીડાશે. અને તમે આ સમસ્યાઓનો સામનો કરો તે પહેલાં તમે આની નોંધ લેશો.

જો તમારી પાસે સમાન સર્વર પર NGINX છે, તો તમને પણ સમાન સમસ્યા હશે. તે વહેંચાયેલ મેમરી માટે લડશે. અને તમે અહીં વર્ણવેલ સમસ્યાઓ સુધી પહોંચશો નહીં.

પરંતુ બીજી બાજુ, આમાંના કેટલાક પરિમાણો હજુ પણ તમારા માટે સુસંગત રહેશે. ઉદાહરણ તરીકે, sysctl સાથે dirty_ratio સેટ કરો જેથી કરીને તે ખૂબ ઉન્મત્ત ન હોય - કોઈ પણ સંજોગોમાં, આ મદદ કરશે. એક રીતે અથવા બીજી રીતે, તમારી પાસે ડિસ્ક સાથે ક્રિયાપ્રતિક્રિયા હશે. અને તે ખોટી પેટર્ન મુજબ હશે. આ સામાન્ય રીતે પેરામીટર્સ માટે ડિફોલ્ટ છે જે મેં બતાવ્યું છે. અને કોઈ પણ સંજોગોમાં તેમને બદલવું વધુ સારું છે.

પરંતુ NUMA સાથે સમસ્યાઓ હોઈ શકે છે. VmWare, ઉદાહરણ તરીકે, બરાબર વિપરીત સેટિંગ્સ સાથે NUMA સાથે સારી રીતે કામ કરે છે. અને અહીં તમારે પસંદ કરવું પડશે - આયર્ન સર્વર અથવા બિન-લોખંડ.

મારી પાસે Amazon AWS થી સંબંધિત પ્રશ્ન છે. તેમની પાસે પૂર્વ-રૂપરેખાંકિત છબીઓ છે. તેમાંથી એક એમેઝોન આરડીએસ કહેવાય છે. શું તેમની ઓપરેટિંગ સિસ્ટમ માટે કોઈ કસ્ટમ સેટિંગ્સ છે?

ત્યાં સેટિંગ્સ છે, પરંતુ તે અલગ સેટિંગ્સ છે. ડેટાબેઝ આ વસ્તુનો ઉપયોગ કેવી રીતે કરશે તે સંદર્ભમાં અમે અહીં ઓપરેટિંગ સિસ્ટમને ગોઠવીએ છીએ. અને એવા પરિમાણો છે જે નક્કી કરે છે કે આપણે હવે ક્યાં જવું જોઈએ, જેમ કે આકાર આપવો. એટલે કે, આપણને ઘણા સંસાધનોની જરૂર છે, હવે આપણે તેને ખાઈશું. આ પછી, એમેઝોન આરડીએસ આ સંસાધનોને સજ્જડ કરે છે, અને કાર્યક્ષમતામાં ઘટાડો થાય છે. લોકો આ બાબતમાં કેવી રીતે ગડબડ કરવાનું શરૂ કરે છે તેની વ્યક્તિગત વાર્તાઓ છે. ક્યારેક તદ્દન સફળતાપૂર્વક પણ. પરંતુ આને OS સેટિંગ્સ સાથે કોઈ લેવાદેવા નથી. તે ક્લાઉડને હેક કરવા જેવું છે. તે એક અલગ વાર્તા છે.

વિશાળ TLB ની સરખામણીમાં પારદર્શક વિશાળ પૃષ્ઠોની કોઈ અસર કેમ નથી?

આપશો નહીં. આ ઘણી રીતે સમજાવી શકાય છે. પરંતુ હકીકતમાં તેઓ તે આપતા નથી. PostgreSQL નો ઇતિહાસ શું છે? સ્ટાર્ટઅપ પર, તે વહેંચાયેલ મેમરીનો મોટો ભાગ ફાળવે છે. તેઓ પારદર્શક છે કે નહીં તે સંપૂર્ણપણે અપ્રસ્તુત છે. હકીકત એ છે કે તેઓ શરૂઆતમાં બહાર આવે છે તે બધું સમજાવે છે. અને જો ત્યાં ઘણી બધી મેમરી છે અને તમારે શેર્ડ_મેમરી સેગમેન્ટને ફરીથી બનાવવાની જરૂર છે, તો પારદર્શક વિશાળ પૃષ્ઠો સંબંધિત હશે. PostgreSQL માં, તે શરૂઆતમાં એક વિશાળ હિસ્સામાં ફાળવવામાં આવે છે અને તે જ છે, અને પછી ત્યાં કંઈ ખાસ થતું નથી. તમે, અલબત્ત, તેનો ઉપયોગ કરી શકો છો, પરંતુ જ્યારે તે કંઈક ફરીથી ફાળવે છે ત્યારે વહેંચાયેલ_મેમરીનો ભ્રષ્ટાચાર થવાની સંભાવના છે. PostgreSQL આ વિશે જાણતું નથી.

સોર્સ: www.habr.com