પોસ્ટગ્રેએસક્યુએલને ટ્યુન કરવા માટેનો ઔદ્યોગિક અભિગમ: ડેટાબેસેસ સાથે પ્રયોગો." નિકોલે સમોખવાલોવ

હું સૂચન કરું છું કે તમે નિકોલાઈ સમોખવાલોવના અહેવાલની ટ્રાંસ્ક્રિપ્ટ વાંચો "પોસ્ટગ્રેએસક્યુએલ ટ્યુનિંગ માટે ઔદ્યોગિક અભિગમ: ડેટાબેસેસ પર પ્રયોગો"

વહેંચાયેલ_બફર્સ = 25% - તે ઘણું છે કે થોડું? અથવા માત્ર અધિકાર? તમે કેવી રીતે જાણો છો કે આ - તેના બદલે જૂનું - તમારા ચોક્કસ કિસ્સામાં ભલામણ યોગ્ય છે?

postgresql.conf પરિમાણોને "પુખ્ત વયની જેમ" પસંદ કરવાના મુદ્દાનો સંપર્ક કરવાનો સમય છે. અંધ "ઓટો ટ્યુનર્સ" અથવા લેખો અને બ્લોગ્સની જૂની સલાહની મદદથી નહીં, પરંતુ તેના આધારે:

1. ડેટાબેસેસ પર સખત રીતે ચકાસાયેલ પ્રયોગો, આપોઆપ, મોટા જથ્થામાં અને શક્ય તેટલી નજીકની પરિસ્થિતિઓ હેઠળ "લડાઈ" કરતા,
2. DBMS અને OS ની વિશેષતાઓની ઊંડી સમજ.

નેન્સી CLI નો ઉપયોગ કરીને (https://gitlab.com/postgres.ai/nancy), અમે એક વિશિષ્ટ ઉદાહરણ જોઈશું - કુખ્યાત વહેંચાયેલ_બફર્સ - વિવિધ પરિસ્થિતિઓમાં, વિવિધ પ્રોજેક્ટ્સમાં અને અમારા ઈન્ફ્રાસ્ટ્રક્ચર, ડેટાબેઝ અને લોડ માટે શ્રેષ્ઠ સેટિંગ કેવી રીતે પસંદ કરવી તે શોધવાનો પ્રયાસ કરીશું.

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

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

મીટઅપ પર પણ RuPostgres જૂથ, વિશ્વમાં 2જું સ્થાન. અમે ધીમે ધીમે 2 લોકો સુધી પહોંચી રહ્યા છીએ. RuPostgres.org.

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

અને છેલ્લા કેટલાક વર્ષોમાં, મેં અહીંથી મારી પોસ્ટગ્રેસ કન્સલ્ટિંગ પ્રેક્ટિસ 11 ટાઇમ ઝોનને ફરીથી શરૂ કરી છે.

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

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

આ અહેવાલમાં શામેલ હશે નહીં:

• "સિલ્વર બુલેટ્સ" અને નિવેદનો જેવા કે - 8 GB અથવા 25% શેર કરેલ_બફર્સ સેટ કરો અને તમે ઠીક થઈ જશો. શેર કરેલ_બફર્સ વિશે ઘણું બધું હશે નહીં.
• હાર્ડકોર "ઇન્નાર્ડ્સ".

શું થશે?

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

આ બધું કેવી રીતે વિકસી રહ્યું છે?

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

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

અને ત્યાં બે અભિગમો છે. Pg_stat_statements એ ધીમી ક્વેરીઝને ઓળખવા માટે મૂળભૂત ઉકેલ છે. અને pgBadger નો ઉપયોગ કરીને પોસ્ટગ્રેસ લોગનું વિશ્લેષણ.

દરેક અભિગમમાં ગંભીર ખામીઓ છે. પ્રથમ અભિગમમાં, અમે તમામ પરિમાણોને બહાર ફેંકી દીધા છે. અને જો આપણે સિલેક્ટ * ફ્રોમ ટેબલ જૂથો જોઈએ જ્યાં કોલમ "?" ની બરાબર છે. અથવા Postgres 10 થી “$”. અમને ખબર નથી કે આ ઇન્ડેક્સ સ્કેન છે કે seq સ્કેન. તે પરિમાણ પર ખૂબ આધાર રાખે છે. જો તમે ત્યાં ભાગ્યે જ જોવા મળતું મૂલ્ય બદલો છો, તો તે ઇન્ડેક્સ સ્કેન હશે. જો તમે ટેબલનો 90% કબજો ધરાવતા મૂલ્યને બદલે, તો seq સ્કેન સ્પષ્ટ થશે, કારણ કે Postgres આંકડાઓ જાણે છે. અને pg_stat_statements ની આ એક મોટી ખામી છે, જોકે અમુક કામ ચાલુ છે.

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

DBAs તેમને મળેલી સમસ્યાઓનું નિરાકરણ કેવી રીતે કરે છે?

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

• રૂપરેખાંકનોને ટ્યુન કરો.
• અનુક્રમણિકાઓના સમૂહને ઑપ્ટિમાઇઝ કરો.
• એસક્યુએલ ક્વેરી પોતે જ બદલો (આ સૌથી મુશ્કેલ રીત છે).
• ક્ષમતા ઉમેરો (મોટા ભાગના કિસ્સાઓમાં સૌથી સહેલો રસ્તો).

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

અને હું આ કાળા જાદુ સામે લડવૈયા છું. હું બધું કરવા માંગુ છું જેથી તકનીક હોય, અને આ બધામાં કોઈ અંતર્જ્ઞાન ન હોય.

વાસ્તવિક જીવન ઉદાહરણો

મેં મારા પોતાના સહિત ઓછામાં ઓછા બે પ્રોજેક્ટ્સમાં આનું અવલોકન કર્યું. અન્ય બ્લોગ પોસ્ટ અમને કહે છે કે default_statistict_target માટે 1 નું મૂલ્ય સારું છે. ઠીક છે, ચાલો તેને ઉત્પાદનમાં અજમાવીએ.

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

અને આ માટે આપણે એક પ્રયોગ બનાવવાની જરૂર છે. તે ચાર ભાગો સમાવે છે.

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

અમે એક પ્રયોગ શરૂ કરી રહ્યા છીએ. અહીં pg_stat_statements છે. ડાબી બાજુ શું થયું છે. જમણી બાજુએ - શું થયું.

ડાબી બાજુએ default_statistics_target = 100, જમણી બાજુએ =1. અમે જોયું કે આનાથી અમને મદદ મળી. એકંદરે, બધું 000% દ્વારા સારું થયું.

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

અથવા આપણે ખોદી ન શકીએ, પરંતુ "કોષ્ટક બદલો ... ALTER કૉલમ" કરી શકીએ અને આ કૉલમના આંકડા પર 100 બકેટ પાછા આપીએ. અને પછી બીજા પ્રયોગથી આપણે ખાતરી કરી શકીએ કે આ પેચ મદદ કરે છે. બધા. આ એક ઇજનેરી અભિગમ છે જે આપણને મોટું ચિત્ર જોવામાં અને અંતર્જ્ઞાનને બદલે ડેટાના આધારે નિર્ણય લેવામાં મદદ કરે છે.

અન્ય ક્ષેત્રોના કેટલાક ઉદાહરણો. ઘણા વર્ષોથી પરીક્ષણમાં CI પરીક્ષણો છે. અને કોઈપણ પ્રોજેક્ટ તેના સાચા મગજમાં સ્વચાલિત પરીક્ષણો વિના જીવશે નહીં.

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

અમે અન્ય ઉદ્યોગોના અવલોકનો પરથી તારણો કાઢી શકીએ છીએ.

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

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

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

નેન્સી CLI - "ડેટાબેઝ લેબોરેટરી" નો પાયો

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

નેન્સી - તે Gitlab પર ઓપન સોર્સમાં છે. તમે તેને કહી શકો છો, તમે તેને અજમાવી શકો છો. મેં સ્લાઇડ્સમાં લિંક આપી છે. તમે તેના પર ક્લિક કરી શકો છો અને તે ત્યાં હશે મદદ બધી બાબતોમાં.

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

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

અને સ્પોટમાં, EC2 ઇન્સ્ટન્સમાં એમેઝોનમાં રિમોટલી ચલાવવાની તક પણ છે. અને આ એક ખૂબ જ સરસ તક છે. ઉદાહરણ તરીકે, ગઈકાલે અમે i500 દાખલા પર 3 થી વધુ પ્રયોગો કર્યા, જે સૌથી નાનાથી શરૂ કરીને i3-16-xlarge સાથે સમાપ્ત થાય છે. અને 500 પ્રયોગો માટે અમને $64 ખર્ચ થાય છે. દરેક 15 મિનિટ ચાલ્યો. એટલે કે, ત્યાં સ્પોટ્સનો ઉપયોગ થાય છે તે હકીકતને કારણે, તે ખૂબ સસ્તું છે - 70% ડિસ્કાઉન્ટ, એમેઝોનનું પ્રતિ-સેકન્ડ બિલિંગ. તમે ઘણું બધું કરી શકો છો. તમે વાસ્તવિક સંશોધન કરી શકો છો.

અને Postgres ના ત્રણ મુખ્ય સંસ્કરણો સપોર્ટેડ છે. કેટલાક જૂના અને નવા 12મા સંસ્કરણને પણ સમાપ્ત કરવું એટલું મુશ્કેલ નથી.

આપણે કોઈ વસ્તુને ત્રણ રીતે વ્યાખ્યાયિત કરી શકીએ છીએ. આ:

• ડમ્પ/sql ફાઇલ.
• મુખ્ય માર્ગ PGDATA ડિરેક્ટરીને ક્લોન કરવાનો છે. એક નિયમ તરીકે, તે બેકઅપ સર્વરમાંથી લેવામાં આવે છે. જો તમારી પાસે સામાન્ય બાઈનરી બેકઅપ હોય, તો તમે ત્યાંથી ક્લોન્સ બનાવી શકો છો. જો તમારી પાસે વાદળો છે, તો એમેઝોન અને ગૂગલ જેવી ક્લાઉડ ઓફિસ તમારા માટે આ કરશે. વાસ્તવિક ઉત્પાદનને ક્લોન કરવાની આ સૌથી મહત્વપૂર્ણ રીત છે. આ રીતે આપણે પ્રગટ કરીએ છીએ.
• અને છેલ્લી પદ્ધતિ સંશોધન માટે યોગ્ય છે જ્યારે તમે સમજવા માંગતા હોવ કે પોસ્ટગ્રેસમાં કંઈક કેવી રીતે કાર્ય કરે છે. આ pgbench છે. તમે pgbench નો ઉપયોગ કરીને જનરેટ કરી શકો છો. તે માત્ર એક "db-pgbench" વિકલ્પ છે. તમે તેને કયો સ્કેલ કહો. અને કહ્યું તેમ બધું જ ક્લાઉડમાં જનરેટ થશે.

અને લોડ કરો:

• અમે એક SQL થ્રેડમાં લોડ એક્ઝિક્યુટ કરી શકીએ છીએ. આ સૌથી આદિમ માર્ગ છે.
• અને અમે ભારનું અનુકરણ કરી શકીએ છીએ. અને આપણે સૌ પ્રથમ નીચેની રીતે તેનું અનુકરણ કરી શકીએ છીએ. આપણે બધા લોગ એકત્રિત કરવાની જરૂર છે. અને તે પીડાદાયક છે. હું તમને શા માટે બતાવીશ. અને pgreplay નો ઉપયોગ કરીને અમે રમીએ છીએ, જે નેન્સીમાં બનેલ છે.
• અથવા અન્ય વિકલ્પ. કહેવાતા ક્રાફ્ટ લોડ, જે આપણે ચોક્કસ રકમના પ્રયત્નો સાથે કરીએ છીએ. લડાઇ પ્રણાલી પરના અમારા વર્તમાન ભારનું વિશ્લેષણ કરીને, અમે વિનંતીઓના ટોચના જૂથોને બહાર કાઢીએ છીએ. અને pgbench નો ઉપયોગ કરીને આપણે પ્રયોગશાળામાં આ લોડનું અનુકરણ કરી શકીએ છીએ.

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

• એક ડિરેક્ટરી pg સ્નેપશોટથી શરૂ કરીને વિવિધ ફાઇલોના સમૂહ સાથે આવે છેstat*** અને સૌથી રસપ્રદ બાબત એ છે pg_stat_statements, pg_stat_kcacke. આ બે એક્સ્ટેન્શન્સ છે જે વિનંતીઓનું વિશ્લેષણ કરે છે. અને pg_stat_bgwriter માત્ર pgwriter આંકડાઓ જ નહીં, પણ ચેકપોઇન્ટ પર અને કેવી રીતે બેકએન્ડ્સ પોતે ગંદા બફરને વિસ્થાપિત કરે છે તે પણ સમાવે છે. અને તે બધું જોવાનું રસપ્રદ છે. ઉદાહરણ તરીકે, જ્યારે અમે શેર કરેલ_બફર્સ સેટ કરીએ છીએ, ત્યારે દરેક વ્યક્તિએ કેટલું બદલ્યું તે જોવાનું ખૂબ જ રસપ્રદ છે.
• પોસ્ટગ્રેસ લોગ પણ આવી રહ્યા છે. બે લોગ - એક તૈયારી લોગ અને લોડ પ્લેબેક લોગ.
• પ્રમાણમાં નવી સુવિધા ફ્લેમગ્રાફ્સ છે.
• ઉપરાંત, જો તમે લોડ વગાડવા માટે pgreplay અથવા pgbench વિકલ્પોનો ઉપયોગ કર્યો હોય, તો તેમનું આઉટપુટ મૂળ હશે. અને તમે લેટન્સી અને TPS જોશો. તેઓએ તેને કેવી રીતે જોયું તે સમજવું શક્ય બનશે.
• સિસ્ટમ માહિતી.
• મૂળભૂત CPU અને IO તપાસો. એમેઝોનમાં EC2 દાખલા માટે આ વધુ છે, જ્યારે તમે થ્રેડમાં 100 સરખા દાખલાઓ લોંચ કરવા અને ત્યાં 100 અલગ-અલગ રન ચલાવવા માંગો છો, તો તમારી પાસે 10 પ્રયોગો હશે. અને તમારે એ સુનિશ્ચિત કરવાની જરૂર છે કે તમે કોઈ ખામીયુક્ત દાખલો ન આવો કે જે પહેલાથી જ કોઈ વ્યક્તિ દ્વારા જુલમ કરવામાં આવી રહ્યો છે. અન્ય હાર્ડવેરના આ ભાગ પર સક્રિય છે અને તમારી પાસે ઓછા સંસાધન બાકી છે. આવા પરિણામોને છોડી દેવાનું વધુ સારું છે. અને એલેક્સી કોપીટોવની sysbench ની મદદથી, અમે ઘણી ટૂંકી તપાસો કરીએ છીએ જે આવશે અને તેની તુલના અન્ય સાથે કરી શકાય છે, એટલે કે તમે સમજી શકશો કે CPU કેવી રીતે વર્તે છે અને IO કેવી રીતે વર્તે છે.

વિવિધ કંપનીઓના ઉદાહરણના આધારે તકનીકી મુશ્કેલીઓ શું છે?

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

સમયગાળો અને ટાઇમસ્ટેમ્પ સાથે કેટલીક ગૂંચવણો છે. અમે આ આખું રસોડું ખાલી કરીશું. મુખ્ય પ્રશ્ન એ છે કે શું તમને તે પરવડે છે કે નહીં?

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

સમસ્યા એ છે કે તે ઉપલબ્ધ ન પણ હોઈ શકે. સૌ પ્રથમ, તમારે સમજવું આવશ્યક છે કે લોગ પર કઈ સ્ટ્રીમ લખવામાં આવશે. જો તમારી પાસે pg_stat_statements હોય, તો તમે આ ક્વેરીનો ઉપયોગ કરી શકો છો (લિંક સ્લાઇડ્સમાં ઉપલબ્ધ હશે) એ સમજવા માટે કે પ્રતિ સેકન્ડમાં આશરે કેટલા બાઇટ્સ લખવામાં આવશે.

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

અમે જોઈ શકીએ છીએ કે પ્રતિ સેકન્ડમાં 802 વખત આ વિનંતી એક્ઝિક્યુટ થાય છે. અને આપણે જોઈએ છીએ કે bytes_per sec - 300 kB/s વત્તા અથવા ઓછા લખવામાં આવશે. અને, એક નિયમ તરીકે, અમે આવા પ્રવાહને પરવડી શકીએ છીએ.

પણ! હકીકત એ છે કે વિવિધ લોગીંગ સિસ્ટમ્સ છે. અને લોકોનું ડિફોલ્ટ સામાન્ય રીતે "syslog" હોય છે.

અને જો તમારી પાસે syslog છે, તો તમારી પાસે આના જેવું ચિત્ર હોઈ શકે છે. અમે pgbench લઈશું, ક્વેરી લોગિંગને સક્ષમ કરીશું અને શું થાય છે તે જોઈશું.

લૉગિંગ વિના - આ ડાબી બાજુની કૉલમ છે. અમને 161 TPS મળ્યા. syslog સાથે - આ Amazon પર Ubuntu 000 માં છે, અમને 16.04 TPS મળે છે. અને જો આપણે બે અન્ય લોગીંગ પદ્ધતિઓમાં બદલાઈએ, તો પરિસ્થિતિ ઘણી સારી છે. એટલે કે, અમે અપેક્ષા રાખીએ છીએ કે તે ઘટશે, પરંતુ તે જ હદ સુધી નહીં.

અને CentOS 7 પર, જેમાં જર્નલ્ડ પણ ભાગ લે છે, સરળ શોધ વગેરે માટે લૉગ્સને બાઈનરી ફોર્મેટમાં ફેરવે છે, તો તે એક દુઃસ્વપ્ન છે, અમે TPS માં 44 વખત ડ્રોપ કરીએ છીએ.

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

• IOPS નું મૂલ્યાંકન કરો અને પ્રવાહ લખો.
• તમારી લોગીંગ સિસ્ટમ તપાસો.
• જો અંદાજિત ભાર અતિશય મોટો હોય, તો નમૂના લેવાનો વિચાર કરો.

અમારી પાસે pg_stat_statements છે. મેં કહ્યું તેમ, તે હોવું જ જોઈએ. અને અમે ફાઇલમાં દરેક વિનંતીના જૂથને વિશિષ્ટ રીતે લઈ અને તેનું વર્ણન કરી શકીએ છીએ. અને પછી અમે pgbench માં ખૂબ જ અનુકૂળ સુવિધાનો ઉપયોગ કરી શકીએ છીએ - આ "-f" વિકલ્પનો ઉપયોગ કરીને ઘણી ફાઇલો દાખલ કરવાની ક્ષમતા છે.

તે "-f" ને ઘણું સમજે છે. અને તમે અંતે “@” ની મદદથી કહી શકો છો કે દરેક ફાઇલમાં શું શેર હોવું જોઈએ. એટલે કે, આપણે કહી શકીએ કે આ 10% કિસ્સાઓમાં કરો, અને આ 20% માં. અને આ આપણને ઉત્પાદનમાં જે જોઈએ છે તેની નજીક લાવશે.

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

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

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

સમસ્યા એ છે કે જ્યારે તમે મોટી કંપનીને મદદ કરો છો, ત્યારે તેઓ ઝડપથી કંઈક અમલ કરી શકતા નથી. તેઓ ઝડપથી ઓકેમીટર ખરીદી શકતા નથી. કદાચ તેઓ તેને છ મહિનામાં ખરીદી લેશે. તેઓ ઝડપથી કેટલાક પેકેજો પહોંચાડી શકતા નથી.

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

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

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

પ્રશ્નોના સૌથી વધુ "પ્રભાવશાળી" જૂથો એકત્રિત કરવા - પોસ્ટગ્રેસ-ચેકઅપમાં K003 નો અહેવાલ આપો

અને અહેવાલોનું જૂથ છે કે. અત્યાર સુધીમાં ત્રણ અહેવાલો. અને આવા અહેવાલ K003 છે. pg_stat_statements માંથી ટોપ છે, ટોટલ_ટાઇમ દ્વારા સૉર્ટ કરેલ છે.

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

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

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

આ ટેબલમાં શું થયું? અમે બે સ્નેપશોટ લીધા. પોસ્ટગ્રેસ_ચેકઅપ તમને દરેક મેટ્રિક માટે ડેલ્ટા આપશે: કુલ-સમય, કૉલ્સ, પંક્તિઓ, શેર કરેલ_બ્લક્સ_રીડ, વગેરે. બસ, ડેલ્ટાની ગણતરી કરવામાં આવી છે. pg_stat_statements સાથે મોટી સમસ્યા એ છે કે તે ક્યારે રીસેટ કરવામાં આવ્યું હતું તે યાદ નથી. જો pg_stat_database યાદ રહે છે, તો pg_stat_statements યાદ નથી. તમે જુઓ છો કે ત્યાં 1 ની સંખ્યા છે, પરંતુ અમને ખબર નથી કે અમે ક્યાંથી ગણ્યા.

અને અહીં આપણે જાણીએ છીએ, અહીં આપણી પાસે બે સ્નેપશોટ છે. આપણે જાણીએ છીએ કે આ કેસમાં ડેલ્ટા 56 સેકન્ડનો હતો. ખૂબ જ ટૂંકું અંતર. કુલ_સમય દ્વારા સૉર્ટ કરેલ. અને પછી આપણે તફાવત કરી શકીએ છીએ, એટલે કે આપણે બધા મેટ્રિક્સને અવધિ દ્વારા વિભાજિત કરીએ છીએ. જો આપણે દરેક મેટ્રિકને અવધિ દ્વારા વિભાજીત કરીએ, તો અમારી પાસે પ્રતિ સેકન્ડ કૉલ્સની સંખ્યા હશે.

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

આ અમારી જાણ છે, મેં આવું ક્યાંય જોયું નથી. મહેરબાની કરીને નોંધ કરો - આ એક ખૂબ જ સરળ વસ્તુ છે - સેકન્ડ પ્રતિ સેકન્ડ. કેટલીકવાર, જ્યારે તમારું CPU 100% હોય, તો પછી અડધો કલાક પ્રતિ સેકન્ડ, એટલે કે, તમે માત્ર આ વિનંતીઓ કરવામાં અડધો કલાક પસાર કર્યો.

આગળ આપણે પ્રતિ સેકન્ડ પંક્તિઓ જોઈએ છીએ. અમે જાણીએ છીએ કે તે પ્રતિ સેકન્ડ કેટલી પંક્તિઓ પરત કરે છે.

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

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

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

અને દરેક લીટીમાં ચોથો સબસ્ટ્રિંગ કુલ કેટલા ટકા છે. અમારી પાસે કૉલ્સ છે. ચાલો કહીએ 1. અને આપણે સમજી શકીએ છીએ કે આ જૂથ શું યોગદાન આપે છે. આપણે જોઈએ છીએ કે આ કિસ્સામાં પ્રથમ જૂથ 000% કરતા ઓછું યોગદાન આપે છે. એટલે કે, તે એટલું ધીમું છે કે આપણે તેને એકંદર ચિત્રમાં જોતા નથી. અને બીજા જૂથમાં 000% કૉલ્સ છે. એટલે કે, તમામ કોલ્સમાંથી 0,01% બીજા જૂથના છે.

કુલ_સમય પણ રસપ્રદ છે. અમે અમારા કુલ કાર્ય સમયના 14% વિનંતીઓના પ્રથમ જૂથ પર ખર્ચ્યા છે. અને બીજા માટે - 11%, વગેરે.

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

પછી અમે અમારા વિષય પર પાછા ફરો. આપણે વર્કલોડ તૈયાર કરવાની જરૂર છે. અમે તેને ઉપરથી નીચે લઈ જઈએ છીએ અને જ્યાં સુધી આપણે 80% અથવા 90% સુધી પહોંચીએ ત્યાં સુધી જઈએ છીએ. સામાન્ય રીતે આ 10-20 જૂથો છે. અને અમે pgbench માટે ફાઇલો બનાવીએ છીએ. અમે ત્યાં રેન્ડમ ઉપયોગ. કેટલીકવાર આ, કમનસીબે, કામ કરતું નથી. અને Postgres 12 માં આ અભિગમનો ઉપયોગ કરવાની વધુ તકો હશે.

અને પછી આપણે આ રીતે કુલ_સમયમાં 80-90% મેળવીએ છીએ. મારે “@” પછી આગળ શું મૂકવું જોઈએ? અમે કૉલ્સ જોઈએ છીએ, ત્યાં કેટલું વ્યાજ છે તે જોઈએ છીએ અને સમજીએ છીએ કે અમારે અહીં આટલું વ્યાજ બાકી છે. આ ટકાવારીઓ પરથી આપણે સમજી શકીએ છીએ કે દરેક ફાઇલને કેવી રીતે સંતુલિત કરવી. તે પછી અમે pgbench નો ઉપયોગ કરીએ છીએ અને કામ પર જઈએ છીએ.

અમારી પાસે K001 અને K002 પણ છે.

K001 એ ચાર સબસ્ટ્રિંગ સાથેની એક મોટી સ્ટ્રિંગ છે. આ આપણા સમગ્ર ભારની લાક્ષણિકતા છે. બીજી કૉલમ અને બીજી સબરો જુઓ. આપણે જોઈએ છીએ કે લગભગ દોઢ સેકન્ડ પ્રતિ સેકન્ડ એટલે કે બે કોરો હોય તો સારું રહેશે. અંદાજે 75% ક્ષમતા હશે. અને તે આ રીતે કામ કરશે. જો આપણી પાસે 10 કોરો હોય, તો આપણે સામાન્ય રીતે શાંત રહીશું. આ રીતે આપણે સંસાધનોનું મૂલ્યાંકન કરી શકીએ છીએ.

K002 એ છે જેને હું ક્વેરી ક્લાસ કહું છું, એટલે કે SELECT, INSERT, UPDATE, DELETE. અને અપડેટ માટે અલગથી પસંદ કરો, કારણ કે તે લોક છે.

અને અહીં આપણે નિષ્કર્ષ પર આવી શકીએ છીએ કે SELECT એ સામાન્ય વાચકો છે - તમામ કૉલ્સના 82%, પરંતુ તે જ સમયે - કુલ_સમયમાં 74%. એટલે કે, તેમને ઘણું કહેવામાં આવે છે, પરંતુ ઓછા સંસાધનોનો ઉપયોગ કરે છે.

અને અમે પ્રશ્ન પર પાછા આવીએ છીએ: "અમે કેવી રીતે યોગ્ય વહેંચાયેલ_બફર્સ પસંદ કરી શકીએ?" હું અવલોકન કરું છું કે મોટાભાગના બેન્ચમાર્ક વિચાર પર આધારિત છે - ચાલો જોઈએ કે થ્રુપુટ શું હશે, એટલે કે થ્રુપુટ શું હશે. તે સામાન્ય રીતે TPS અથવા QPS માં માપવામાં આવે છે.

અને અમે ટ્યુનિંગ પરિમાણોનો ઉપયોગ કરીને કારમાંથી શક્ય તેટલા સેકન્ડ પ્રતિ સેકન્ડ જેટલા વ્યવહારો બહાર કાઢવાનો પ્રયાસ કરીએ છીએ. અહીં પસંદગી માટે બરાબર 311 પ્રતિ સેકન્ડ છે.

પરંતુ કોઈ પણ કામ પર જવા માટે અને સંપૂર્ણ ઝડપે ઘરે પાછા ફરતું નથી. આ મૂર્ખ છે. ડેટાબેસેસ સાથે સમાન. અમારે પૂરપાટ ઝડપે વાહન ચલાવવાની જરૂર નથી, અને કોઈ કરતું નથી. ઉત્પાદનમાં કોઈ રહેતું નથી, જેની પાસે 100% CPU છે. તેમ છતાં, કદાચ કોઈ જીવે છે, પરંતુ આ સારું નથી.

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

અને અંતે, ભલામણો:

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

પ્રશ્નો

ખુબ ખુબ આભાર! એક ખૂબ જ રસપ્રદ વાત.

બે ટુકડા.

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

અમારી પાસે ડેલ્ટા રૂપરેખા પરિમાણ છે. તમે એક જ વારમાં જોઈએ તેટલું ત્યાં ફેરવી શકો છો. પરંતુ તમારે એ સમજવાની જરૂર છે કે જ્યારે તમે ઘણી વસ્તુઓ બદલો છો, ત્યારે તમે ખોટા તારણો કાઢી શકો છો.

હા. મેં કેમ પૂછ્યું? કારણ કે જ્યારે તમારી પાસે માત્ર એક પરિમાણ હોય ત્યારે પ્રયોગો કરવા મુશ્કેલ છે. તમે તેને સજ્જડ કરો, જુઓ કે તે કેવી રીતે કાર્ય કરે છે. મેં તેને બહાર કાઢ્યો. પછી તમે આગલું શરૂ કરો.

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

અને બીજો પ્રશ્ન છે. પ્રોજેક્ટ યુવાન અને વિકાસશીલ છે. દસ્તાવેજીકરણ પહેલેથી જ તૈયાર છે, શું વિગતવાર વર્ણન છે?

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

એકવાર અમે પ્રયોગશાળા બનાવીશું, કદાચ પ્રતિસાદ મળશે. જોઈએ. આભાર!

નમસ્તે! રિપોર્ટ માટે આભાર! મેં જોયું કે એમેઝોન સપોર્ટ છે. શું GSP ને ટેકો આપવાની કોઈ યોજના છે?

સારો પ્રશ્ન. અમે તે કરવાનું શરૂ કર્યું. અને અમે તેને હમણાં માટે સ્થિર કરી દીધું છે કારણ કે અમે પૈસા બચાવવા માંગીએ છીએ. એટલે કે, લોકલહોસ્ટ પર રનનો ઉપયોગ કરીને સપોર્ટ છે. તમે જાતે દાખલો બનાવી શકો છો અને સ્થાનિક રીતે કામ કરી શકો છો. માર્ગ દ્વારા, તે અમે શું છે. હું આ ગેટલેબમાં, ત્યાં જીએસપી પર કરું છું. પરંતુ અમે હજી સુધી આવા ઓર્કેસ્ટ્રેશન કરવાનો મુદ્દો જોતા નથી, કારણ કે Google પાસે સસ્તા સ્થળો નથી. ત્યાં છે ??? દાખલાઓ, પરંતુ તેમની મર્યાદાઓ છે. પ્રથમ, તેમની પાસે હંમેશા માત્ર 70% ડિસ્કાઉન્ટ હોય છે અને તમે ત્યાં કિંમત સાથે રમી શકતા નથી. સ્પોટ્સ પર, તમને લાત મારવામાં આવશે તેવી સંભાવના ઘટાડવા માટે અમે કિંમતમાં 5-10% વધારો કરીએ છીએ. એટલે કે, તમે ફોલ્લીઓ બચાવો છો, પરંતુ તે કોઈપણ સમયે તમારી પાસેથી છીનવી શકાય છે. જો તમે બીજા કરતા થોડી વધારે બોલી લગાવશો, તો તમને પાછળથી મારી નાખવામાં આવશે. Google પાસે સંપૂર્ણપણે અલગ વિશિષ્ટતાઓ છે. અને બીજી ખૂબ જ ખરાબ મર્યાદા છે - તેઓ ફક્ત 24 કલાક જીવે છે. અને ક્યારેક અમે 5 દિવસ માટે પ્રયોગ ચલાવવા માંગીએ છીએ. પરંતુ તમે આ ફોલ્લીઓમાં કરી શકો છો; ફોલ્લીઓ ક્યારેક મહિનાઓ સુધી રહે છે.

નમસ્તે! રિપોર્ટ માટે આભાર! તમે ચેકઅપનો ઉલ્લેખ કર્યો છે. તમે સ્ટેટ_સ્ટેટમેન્ટની ભૂલોની ગણતરી કેવી રીતે કરશો?

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

શું તમે ડરતા નથી કે સ્નેપશોટ વચ્ચેના સમય દરમિયાન તે ત્યાં બે કે ત્રણ વાર વળશે?

એટલે કે, તેઓએ ફરીથી નોંધણી કરાવી કે શું?

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

સારો પ્રશ્ન, આપણે જોવું પડશે.

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

હા હા.

પરંતુ હું સમજી શકતો નથી કે તે કેવી રીતે વિશ્વસનીય રીતે કરવું.

કમનસીબે, મને બરાબર યાદ નથી કે આપણે ત્યાં ક્વેરી ટેક્સ્ટનો ઉપયોગ કરીએ છીએ અથવા pg_stat_statements સાથે queryid અને તેના પર ધ્યાન કેન્દ્રિત કરીએ છીએ. જો આપણે queryid પર ધ્યાન કેન્દ્રિત કરીએ, તો સિદ્ધાંતમાં આપણે તુલનાત્મક વસ્તુઓની તુલના કરી રહ્યા છીએ.

ના, તેને સ્નેપશોટ વચ્ચે ઘણી વખત બળજબરીથી બહાર કાઢી શકાય છે અને ફરીથી આવી શકે છે.

એ જ આઈડી સાથે?

હા.

અમે આનો અભ્યાસ કરીશું. સારો પ્રશ્ન. આપણે તેનો અભ્યાસ કરવાની જરૂર છે. પરંતુ અત્યારે, આપણે જે જોઈએ છીએ તે કાં તો 0 લખેલું છે...

આ, અલબત્ત, એક દુર્લભ કિસ્સો છે, પરંતુ જ્યારે મને જાણવા મળ્યું કે stat_statemetns ત્યાં વિસ્થાપિત થઈ શકે છે ત્યારે મને આઘાત લાગ્યો.

Pg_stat_statements માં ઘણી વસ્તુઓ હોઈ શકે છે. અમને એ હકીકત જાણવા મળી કે જો તમારી પાસે track_utility = ચાલુ હોય, તો તમારા સેટ પણ ટ્રેક કરવામાં આવે છે.

હા અલબત્ત.

અને જો તમારી પાસે જાવા હાઇબરનેટ છે, જે રેન્ડમ છે, તો હેશ ટેબલ ત્યાં સ્થિત થવાનું શરૂ થાય છે. અને જલદી તમે ખૂબ જ લોડ કરેલી એપ્લિકેશન બંધ કરો છો, તમે 50-100 જૂથો સાથે સમાપ્ત થશો. અને ત્યાં બધું વધુ કે ઓછું સ્થિર છે. આનો સામનો કરવાની એક રીત છે pg_stat_statements.max ને વધારવી.

હા, પણ તમારે કેટલું જાણવાની જરૂર છે. અને કોઈક રીતે આપણે તેના પર નજર રાખવાની જરૂર છે. તે હું શું કરું છું. એટલે કે, મારી પાસે pg_stat_statements.max છે. અને હું જોઉં છું કે સ્નેપશોટ સમયે હું 70% સુધી પહોંચ્યો ન હતો. ઠીક છે, તેથી અમે કંઈપણ ગુમાવ્યું નથી. ચાલો રીસેટ કરીએ. અને અમે ફરીથી બચાવીએ છીએ. જો આગળનો સ્નેપશોટ 70 કરતા ઓછો છે, તો સંભવતઃ તમે ફરીથી કંઈપણ ગુમાવ્યું નથી.

હા. ડિફોલ્ટ હવે 5 છે. અને આ ઘણા લોકો માટે પૂરતું છે.

સામાન્ય રીતે હા.

વિડિઓ:

PS મારા પોતાના વતી, હું ઉમેરીશ કે જો Postgres ગોપનીય ડેટા ધરાવે છે અને તે પરીક્ષણ વાતાવરણમાં સમાવી શકાતું નથી, તો તમે ઉપયોગ કરી શકો છો PostgreSQL અનામી. આ યોજના લગભગ નીચે મુજબ છે:

સોર્સ: www.habr.com