PostgreSQL આંતરિક આંકડાઓમાં ઊંડાણપૂર્વક ડાઇવ કરો. એલેક્સી લેસોવ્સ્કી

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

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

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

શુભ બપોર મારું નામ એલેક્સી છે. ઇલ્યાએ કહ્યું તેમ, હું PostgreSQL આંકડા વિશે વાત કરીશ.

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

હું તમને કહીશ કે તમારી પાસે અથવા હોઈ શકે તેવી વિવિધ સમસ્યાઓ ઉકેલવા માટે આંકડાઓનો અસરકારક રીતે ઉપયોગ કેવી રીતે કરવો.

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

અને ત્યાં કોઈ સાધન સમીક્ષાઓ હશે નહીં, હું એક ઉત્પાદનની બીજા સાથે તુલના કરીશ નહીં. કોઈ જાહેરાત હશે નહીં. ચાલો તેને ડ્રોપ કરીએ.

હું તમને બતાવવા માંગુ છું કે આંકડાઓનો ઉપયોગ કરવો ઉપયોગી છે. તે જરૂરી છે. નિર્ભયતાથી તેનો ઉપયોગ કરો. અમને ફક્ત સાદા SQL અને SQL ના મૂળભૂત જ્ઞાનની જરૂર છે.

અને સમસ્યાઓ ઉકેલવા માટે કયા આંકડા પસંદ કરવા તે વિશે અમે વાત કરીશું.

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

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

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

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

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

આંકડા સાથે શું સમસ્યાઓ છે?

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

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

અને તમારે SQL ના મૂળભૂત જ્ઞાનની જરૂર છે. આંકડાઓમાંથી કેટલોક ડેટા મેળવવા માટે, તમારે SQL ક્વેરી કરવાની જરૂર છે, એટલે કે તમારે જાણવાની જરૂર છે કે કેવી રીતે સિલેક્ટ, જોઇન કરવામાં આવે છે.

આંકડા અમને ઘણી વસ્તુઓ કહે છે. તેઓને શ્રેણીઓમાં વિભાજિત કરી શકાય છે.

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

આંકડાઓના સ્ત્રોતો નીચે મુજબ રજૂ કરવામાં આવ્યા છે:

• વહેંચાયેલ મેમરીમાં (શેર કરેલ બફર્સ) ત્યાં સ્ટેટિક ડેટા મૂકવા માટે એક સેગમેન્ટ છે, ત્યાં એવા કાઉન્ટર્સ પણ છે કે જે અમુક ઘટનાઓ બને ત્યારે અથવા ડેટાબેઝના સંચાલનમાં કેટલીક ક્ષણો ઊભી થાય ત્યારે સતત વધારો કરવામાં આવે છે.
• આ તમામ કાઉન્ટર્સ યુઝર માટે ઉપલબ્ધ નથી અને એડમિનિસ્ટ્રેટર માટે પણ ઉપલબ્ધ નથી. આ નિમ્ન સ્તરની વસ્તુઓ છે. તેમને ઍક્સેસ કરવા માટે, PostgreSQL એ SQL ફંક્શનના સ્વરૂપમાં ઇન્ટરફેસ પૂરું પાડે છે. અમે આ કાર્યોનો ઉપયોગ કરીને પસંદગીની પસંદગી કરી શકીએ છીએ અને અમુક પ્રકારનું મેટ્રિક (અથવા મેટ્રિક્સનો સમૂહ) મેળવી શકીએ છીએ.
• જો કે, આ ફંક્શન્સનો ઉપયોગ કરવો હંમેશા અનુકૂળ નથી, તેથી ફંક્શન્સ દૃશ્યો (VIEWs) માટેનો આધાર છે. આ વર્ચ્યુઅલ કોષ્ટકો છે જે ચોક્કસ સબસિસ્ટમ પર અથવા ડેટાબેઝમાં ઇવેન્ટ્સના અમુક સેટ પર આંકડા પ્રદાન કરે છે.
• આ બિલ્ટ-ઇન દૃશ્યો (VIEWs) આંકડાઓ સાથે કામ કરવા માટેનું મુખ્ય વપરાશકર્તા ઇન્ટરફેસ છે. તેઓ કોઈપણ વધારાના સેટિંગ્સ વિના ડિફોલ્ટ રૂપે ઉપલબ્ધ છે, તમે તરત જ તેનો ઉપયોગ કરી શકો છો, જોઈ શકો છો, ત્યાંથી માહિતી લઈ શકો છો. અને યોગદાન પણ છે. યોગદાન સત્તાવાર છે. તમે postgresql-contrib પેકેજ ઇન્સ્ટોલ કરી શકો છો (ઉદાહરણ તરીકે, postgresql94-contrib), રૂપરેખાંકનમાં જરૂરી મોડ્યુલ લોડ કરી શકો છો, તેના માટે પરિમાણો સ્પષ્ટ કરી શકો છો, PostgreSQL પુનઃપ્રારંભ કરો અને તમે તેનો ઉપયોગ કરી શકો છો. (નૉૅધ. વિતરણના આધારે, યોગદાનના તાજેતરના સંસ્કરણોમાં પેકેજ મુખ્ય પેકેજનો ભાગ છે).
• અને બિનસત્તાવાર યોગદાન છે. તેઓ પ્રમાણભૂત PostgreSQL વિતરણ સાથે પૂરા પાડવામાં આવતા નથી. તેઓ કાં તો કમ્પાઇલ અથવા લાઇબ્રેરી તરીકે ઇન્સ્ટોલ કરેલા હોવા જોઈએ. આ બિનસત્તાવાર યોગદાનના વિકાસકર્તાએ શું કર્યું તેના આધારે વિકલ્પો ખૂબ જ અલગ હોઈ શકે છે.

આ સ્લાઇડ તે બધા દૃશ્યો (VIEWs) અને તેમાંથી કેટલાક કાર્યો દર્શાવે છે જે PostgreSQL 9.4 માં ઉપલબ્ધ છે. જેમ આપણે જોઈ શકીએ છીએ, તેમાંના ઘણા બધા છે. અને જો તમે તેને પહેલીવાર અનુભવી રહ્યાં હોવ તો મૂંઝવણમાં પડવું ખૂબ જ સરળ છે.

જો કે, જો આપણે અગાઉનું ચિત્ર લઈએ Как тратится время на PostgreSQL અને આ સૂચિ સાથે સુસંગત, અમને આ ચિત્ર મળે છે. દરેક વ્યુ (VIEWs), અથવા દરેક ફંક્શન, જ્યારે અમારી પાસે PostgreSQL ચાલી રહ્યું હોય ત્યારે અમે યોગ્ય આંકડા મેળવવા માટે એક અથવા બીજા હેતુ માટે ઉપયોગ કરી શકીએ છીએ. અને અમે સબસિસ્ટમના સંચાલન વિશે પહેલેથી જ કેટલીક માહિતી મેળવી શકીએ છીએ.

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

આપણે ત્યાંથી શું લઈ શકીએ? ચાલો સૌથી સરળ વસ્તુઓ સાથે પ્રારંભ કરીએ.

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

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

તે સ્પષ્ટ છે કે અમારી પાસે જેટલી વધુ કેશ હિટ છે, તેટલું સારું. અમે ટકાવારી તરીકે આ મેટ્રિકનું મૂલ્યાંકન કરીએ છીએ. અને, ઉદાહરણ તરીકે, જો આપણી પાસે આ કેશ હિટની ટકાવારી 90% થી વધુ છે, તો આ સારું છે. જો તે 90% થી નીચે જાય છે, તો અમારી પાસે મેમરીમાં ડેટાના હોટ હેડને રાખવા માટે પૂરતી મેમરી નથી. અને આ ડેટાનો ઉપયોગ કરવા માટે, PostgreSQL ને ડિસ્કને ઍક્સેસ કરવાની ફરજ પાડવામાં આવે છે અને જો મેમરીમાંથી ડેટા વાંચવામાં આવ્યો હોય તો તે કરતાં આ ધીમું છે. અને તમારે મેમરી વધારવા વિશે વિચારવાની જરૂર છે: કાં તો વહેંચાયેલ બફર વધારો, અથવા આયર્ન મેમરી (RAM) વધારો.

select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;

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

અમે આ વિનંતીનો ઉપયોગ કરી શકીએ છીએ. આ SQL ખૂબ સરળ છે. અને આપણે આ ડેટા આપણા માટે જોઈ શકીએ છીએ.

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

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

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

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

pg_stat_bgwriter - આ દૃશ્ય બે PostgreSQL પૃષ્ઠભૂમિ સબસિસ્ટમના સંચાલનનું વર્ણન કરે છે: checkpointer и background writer.

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

ચેકપૉઇન્ટ વહેંચાયેલ બફર્સમાંથી પસાર થાય છે, ગંદા પૃષ્ઠોને ચિહ્નિત કરે છે જે ચેકપોઇન્ટ માટે જરૂરી છે. પછી તે વહેંચાયેલ બફર્સમાંથી બીજો પાસ શરૂ કરે છે. અને ચેકપોઇન્ટ માટે ચિહ્નિત થયેલ પૃષ્ઠો, તે પહેલાથી જ તેમને સિંક્રનાઇઝ કરે છે. આમ, ડેટા પહેલેથી જ ડિસ્ક સાથે સિંક્રનાઇઝ થયેલ છે.

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

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

અને ચેકપોઇન્ટને સમાયોજિત કરવા માટે ત્રણ પરિમાણો છે:

• сheckpoint_segments.

• сheckpoint_timeout.

• сheckpoint_competion_target.

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

ચેતવણી: અહેવાલમાં ધ્યાનમાં લેવામાં આવેલ સંસ્કરણ 9.4 હવે સંબંધિત નથી. PostgreSQL ના આધુનિક સંસ્કરણોમાં, પરિમાણ checkpoint_segments પરિમાણો દ્વારા બદલવામાં આવે છે min_wal_size и max_wal_size.

આગામી સબસિસ્ટમ પૃષ્ઠભૂમિ લેખક છે − background writer. તે શુ કરી રહ્યો છે? તે અનંત લૂપમાં સતત ચાલે છે. તે શેર કરેલા બફર્સમાં પૃષ્ઠોને સ્કેન કરે છે અને ડિસ્ક પર મળેલા ગંદા પૃષ્ઠોને ફ્લશ કરે છે. આ રીતે, તે ચેકપોઇન્ટિંગ દરમિયાન ચેકપોઇન્ટરને ઓછું કામ કરવામાં મદદ કરે છે.

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

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

ચેતવણી: _નીચેનું લખાણ પ્રતિકૃતિ સાથે સંકળાયેલ આંકડાકીય દૃશ્યોનું વર્ણન કરે છે. પોસ્ટગ્રેસ 10 માં મોટાભાગના વ્યુ અને ફંક્શન નામોનું નામ બદલવામાં આવ્યું છે. નામ બદલવાનો સાર બદલવાનો હતો. xlog પર wal и location પર lsn ફંક્શન/વ્યુ નામો વગેરેમાં ખાસ ઉદાહરણ, કાર્ય pg_xlog_location_diff() થી નામ આપવામાં આવ્યું હતું pg_wal_lsn_diff()._

અમારી પાસે અહીં પણ ઘણું છે. પરંતુ અમને ફક્ત સ્થાન સંબંધિત વસ્તુઓની જરૂર છે.

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

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

сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());

જો આ વસ્તુઓ અલગ હોય, તો પછી એક પ્રકારનું અંતર છે. લેગ એ માસ્ટરની પ્રતિકૃતિનો લેગ છે, એટલે કે ડેટા સર્વર્સ વચ્ચે અલગ પડે છે.

વિલંબના ત્રણ કારણો છે:

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

અને અહીં ત્રણ પ્રશ્નો છે જે અમને આંકડાઓનો ઉપયોગ કરવાની મંજૂરી આપે છે. અમે અંદાજ લગાવી શકીએ છીએ કે અમારા ટ્રાન્ઝેક્શન લોગમાં કેટલું રેકોર્ડ છે. આવા કાર્ય છે pg_xlog_location_diff અને અમે બાઇટ્સ અને સેકંડમાં પ્રતિકૃતિ લેગનો અંદાજ લગાવી શકીએ છીએ. અમે આ માટે આ દૃશ્ય (VIEWs)માંથી મૂલ્યનો પણ ઉપયોગ કરીએ છીએ.

ઉદાહરણ: pg_xlog_location ને બદલેdiff() ફંક્શન, તમે બાદબાકી ઓપરેટરનો ઉપયોગ કરી શકો છો અને એક સ્થાનને બીજા સ્થાનમાંથી બાદ કરી શકો છો. આરામદાયક.

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

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

select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;

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

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

એક સરળ ઉદાહરણ - ચાલો કહીએ કે મોટી OFFSET અને LIMIT સાથેની વિનંતી યોગ્ય છે. ઉદાહરણ તરીકે, કોષ્ટકમાં 100 પંક્તિઓ સ્કેન કરવામાં આવે છે અને તે પછી 000 જરૂરી પંક્તિઓ લેવામાં આવે છે, અને અગાઉની સ્કેન કરેલી પંક્તિઓ કાઢી નાખવામાં આવે છે. આ પણ એક ખરાબ કેસ છે. અને આવી વિનંતીઓને ઑપ્ટિમાઇઝ કરવાની જરૂર છે. અને અહીં એક સરળ SQL ક્વેરી છે જેના પર તમે તેને જોઈ શકો છો અને પ્રાપ્ત નંબરોનું મૂલ્યાંકન કરી શકો છો.

select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;

આ કોષ્ટકનો ઉપયોગ કરીને અને વધારાના કાર્યોનો ઉપયોગ કરીને કોષ્ટકના કદ પણ મેળવી શકાય છે pg_total_relation_size(), pg_relation_size().

સામાન્ય રીતે, ત્યાં મેટાકમાન્ડ્સ છે dt и di, જેનો તમે PSQL માં ઉપયોગ કરી શકો છો અને ટેબલ અને ઇન્ડેક્સના કદ પણ જોઈ શકો છો.

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

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

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

select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;

અને તેની ડિઝાઇનને કારણે, અપડેટ એ હેવીવેઇટ ઓપરેશન છે. પરંતુ તેઓ સરળ બનાવી શકાય છે. ખાવું hot updates. તેઓ PostgreSQL સંસ્કરણ 8.3 માં દેખાયા. અને આ શું છે? આ એક હળવા વજનનું અપડેટ છે જે અનુક્રમણિકાઓને પુનઃબીલ્ડ થવાનું કારણ આપતું નથી. એટલે કે, અમે રેકોર્ડ અપડેટ કર્યો છે, પરંતુ ફક્ત પૃષ્ઠમાંનો રેકોર્ડ (જે ટેબલનો છે) અપડેટ કરવામાં આવ્યો હતો, અને અનુક્રમણિકાઓ હજી પણ પૃષ્ઠમાં સમાન રેકોર્ડ તરફ નિર્દેશ કરે છે. કામનો થોડો રસપ્રદ તર્ક છે, જ્યારે શૂન્યાવકાશ આવે છે, ત્યારે તેમાં આ સાંકળો હોય છે hot પુનઃનિર્માણ કરે છે અને અનુક્રમણિકાઓને અપડેટ કર્યા વિના બધું કામ કરવાનું ચાલુ રાખે છે, અને બધું સંસાધનોના ઓછા કચરો સાથે થાય છે.

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

ALTER TABLE table_name SET (fillfactor = 70);

વોલ્યુમ કેવી રીતે વધારવું hot updateઓવ? અમે ઉપયોગ કરી શકીએ છીએ fillfactor. INSERTs નો ઉપયોગ કરીને કોષ્ટકમાં પૃષ્ઠ ભરતી વખતે તે અનામત ખાલી જગ્યાનું કદ નક્કી કરે છે. જ્યારે દાખલો ટેબલ પર જાય છે, ત્યારે તેઓ પૃષ્ઠને સંપૂર્ણપણે ભરે છે, તેમાં ખાલી જગ્યા છોડશો નહીં. પછી એક નવું પૃષ્ઠ પ્રકાશિત થાય છે. ડેટા ફરીથી ભરવામાં આવે છે. અને આ ડિફોલ્ટ વર્તન છે, ફિલફેક્ટર = 100%.

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

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

ઓટોવેક્યુમ કતાર. ઑટોવેક્યુમ એ એવી સબસિસ્ટમ છે જેના માટે PostgreSQL માં બહુ ઓછા આંકડા છે. આપણે ફક્ત pg_stat_activity માં કોષ્ટકોમાં જોઈ શકીએ છીએ કે આ ક્ષણે આપણી પાસે કેટલા શૂન્યાવકાશ છે. જો કે, સફરમાં તેની પાસે કતારમાં કેટલા ટેબલ છે તે સમજવું ખૂબ મુશ્કેલ છે.

ઉદાહરણ: _ Postgres 10 થી, શૂન્યાવકાશ વેક્યૂમ ટ્રૅક કરવાની પરિસ્થિતિમાં ઘણો સુધારો થયો છે - pg_stat_progress વ્યુ દેખાયો છેશૂન્યાવકાશ, જે ઑટોવેક્યુમ મોનિટરિંગના મુદ્દાને મોટા પ્રમાણમાં સરળ બનાવે છે.

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

અને આ થ્રેશોલ્ડ કેવી રીતે ગણવામાં આવે છે? આ કોષ્ટકમાં પંક્તિઓની કુલ સંખ્યાની ખૂબ ચોક્કસ ટકાવારી છે. એક પરિમાણ છે autovacuum_vacuum_scale_factor. તે ટકાવારી વ્યાખ્યાયિત કરે છે. ચાલો કહીએ કે 10% + 50 રેખાઓનો વધારાનો આધાર થ્રેશોલ્ડ છે. અને શું થાય છે? જ્યારે અમારી પાસે કોષ્ટકની બધી પંક્તિઓમાંથી "10% + 50" કરતાં વધુ મૃત પંક્તિઓ હોય, ત્યારે અમે ટેબલને ઑટોવેક્યુમ પર મૂકીએ છીએ.

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

જો કે, ત્યાં એક બિંદુ છે. પરિમાણો માટે મૂળભૂત થ્રેશોલ્ડ av_base_thresh и av_scale_factor વ્યક્તિગત રીતે સોંપવામાં આવી શકે છે. અને, તે મુજબ, થ્રેશોલ્ડ વૈશ્વિક નહીં, પરંતુ ટેબલ માટે વ્યક્તિગત હશે. તેથી, ગણતરી કરવા માટે, તમારે યુક્તિઓ અને યુક્તિઓનો ઉપયોગ કરવાની જરૂર છે. અને જો તમને રસ હોય, તો તમે એવિટોના અમારા સાથીદારોના અનુભવને જોઈ શકો છો (સ્લાઇડ પરની લિંક અમાન્ય છે અને ટેક્સ્ટમાં અપડેટ કરવામાં આવી છે).

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

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

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

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

ઉદાહરણ: જ્યારે સ્ટ્રીમિંગ પ્રતિકૃતિ ક્લસ્ટરોના કિસ્સામાં નહિં વપરાયેલ અનુક્રમણિકાઓ શોધી રહ્યા હોય, ત્યારે તમારે ક્લસ્ટરના તમામ ગાંઠો તપાસવાની જરૂર છે, કારણ કે આંકડા વૈશ્વિક નથી, અને જો માસ્ટર પર ઇન્ડેક્સનો ઉપયોગ થતો નથી, તો તેનો ઉપયોગ પ્રતિકૃતિઓ પર થઈ શકે છે (જો ત્યાં ભાર હોય તો).

બે લિંક્સ:

https://github.com/dataegret/pg-utils/blob/master/sql/low_used_indexes.sql

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

ન વપરાયેલ અનુક્રમણિકાઓ કેવી રીતે શોધવી તે માટે આ વધુ અદ્યતન ક્વેરી ઉદાહરણો છે.

બીજી લિંક એક રસપ્રદ પ્રશ્ન છે. એમાં બહુ તુચ્છ તર્ક છે. હું સમીક્ષા માટે ભલામણ કરું છું.

અનુક્રમણિકાઓ દ્વારા બીજું શું સારાંશ આપવું જોઈએ?

• નહિ વપરાયેલ ઇન્ડેક્સ ખરાબ છે.

• તેઓ જગ્યા લે છે.

• અપડેટ કામગીરી ધીમી કરો.

• વેક્યૂમ માટે વધારાનું કામ.

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

આગામી દૃશ્ય છે pg_stat_activity. આ ઉપયોગિતાનું એનાલોગ છે ps, માત્ર PostgreSQL માં. જો ps'ઓહમ તમે ઓપરેટિંગ સિસ્ટમમાં પ્રક્રિયાઓ જુઓ છો, પછી pg_stat_activity તમને PostgreSQL ની અંદરની પ્રવૃત્તિ બતાવશે.

આપણે ત્યાંથી શું લઈ શકીએ?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

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

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

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

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

select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;

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

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

ખરાબ વ્યવહારો વ્યવહારમાં નિષ્ક્રિય છે અને વ્યવહારમાં નિષ્ક્રિય છે (નિષ્ક્રિય) વ્યવહારો.

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

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

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

જો તમે જોશો કે તમારી પાસે તમારા ડેટાબેઝમાં તેમાંથી 5-10-20 થી વધુ છે, તો તમારે ચિંતા કરવાની જરૂર છે અને તેમની સાથે કંઈક કરવાનું શરૂ કરો.

અહીં આપણે ગણતરીના સમય માટે પણ ઉપયોગ કરીએ છીએ clock_timestamp(). અમે વ્યવહારો શૂટ કરીએ છીએ, અમે એપ્લિકેશનને ઑપ્ટિમાઇઝ કરીએ છીએ.

મેં ઉપર કહ્યું તેમ, જ્યારે બે અથવા વધુ વ્યવહારો એક અથવા સંસાધનોના જૂથ માટે સ્પર્ધા કરે છે ત્યારે તાળાઓ હોય છે. આ માટે અમારી પાસે એક ક્ષેત્ર છે waiting બુલિયન મૂલ્ય સાથે true અથવા false.

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

ચેતવણી: પોસ્ટગ્રેસ 9.6 થી શરૂ કરીને, ક્ષેત્ર waiting દૂર કરીને વધુ બે માહિતીપ્રદ ક્ષેત્રો દ્વારા બદલવામાં આવ્યા છે wait_event_type и wait_event._

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

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

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

અને અહીં બે ક્વેરીઝ છે જે તમને તાળાઓ ટ્રૅક કરવાની મંજૂરી આપે છે. અમે દૃશ્યનો ઉપયોગ કરીએ છીએ pg_locks, જે તમને ભારે તાળાઓને ટ્રૅક કરવાની મંજૂરી આપે છે.

અને પ્રથમ લિંક વિનંતી ટેક્સ્ટ પોતે છે. તે ખૂબ લાંબુ છે.

અને બીજી લિંક તાળાઓ પરનો લેખ છે. તે વાંચવા માટે ઉપયોગી છે, તે ખૂબ જ રસપ્રદ છે.

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

આ રીતે આપણે શોધી શકીએ છીએ કે કોણે કોને તાળા માર્યા છે, કોણ કોને પકડી રહ્યું છે, અને આપણે આનો સામનો કરી શકીએ છીએ.

આગળનું મોડ્યુલ છે pg_stat_statements. મેં કહ્યું તેમ, તે એક મોડ્યુલ છે. તેનો ઉપયોગ કરવા માટે, તમારે તેની લાઇબ્રેરીને રૂપરેખાંકનમાં લોડ કરવાની જરૂર છે, PostgreSQL પુનઃપ્રારંભ કરો, મોડ્યુલ ઇન્સ્ટોલ કરો (એક આદેશ સાથે), અને પછી અમારી પાસે એક નવું દૃશ્ય હશે.

Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;

Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;

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

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

અને અમે ફક્ત આ વિનંતીઓ માટે જુદા જુદા આંકડા જોઈ શકીએ છીએ.

https://github.com/dataegret/pg-utils/blob/master/sql/global_reports/query_stat_total.sql

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

આપણે શું કરી રહ્યા છીએ? અમે તમામ વિનંતીઓ માટે એકંદર આંકડાની ગણતરી કરીએ છીએ. પછી, દરેક ક્વેરી માટે, અમે આ એકંદર આંકડામાં તેના વ્યક્તિગત યોગદાનની ગણતરી કરીએ છીએ.

અને આપણે શું જોઈ શકીએ? અમે અન્ય તમામ વિનંતીઓની પૃષ્ઠભૂમિ સામે ચોક્કસ પ્રકારની તમામ વિનંતીઓનો કુલ અમલ સમય જોઈ શકીએ છીએ. અમે એકંદર ચિત્રના સંબંધમાં CPU અને I/O વપરાશ જોઈ શકીએ છીએ. અને પહેલેથી જ આ વિનંતીઓને ઑપ્ટિમાઇઝ કરવા માટે. અમે આ રિપોર્ટના આધારે ટોચની ક્વેરી બનાવી રહ્યા છીએ અને શું ઑપ્ટિમાઇઝ કરવું તે વિશે વિચારવા માટે પહેલેથી જ ખોરાક મેળવી રહ્યા છીએ.

પડદા પાછળ આપણી પાસે શું છે? હજુ પણ અમુક સબમિશન છે જે મેં ધ્યાનમાં લીધા નથી, કારણ કે સમય મર્યાદિત છે.

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

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

આગળનું મોડ્યુલ છે pgfincore. તે તમને સિસ્ટમ કૉલ દ્વારા નિમ્ન-સ્તરની કોષ્ટક કામગીરી કરવા માટે પરવાનગી આપે છે mincore(), એટલે કે તે તમને ટેબલને વહેંચાયેલ બફરમાં લોડ કરવા અથવા તેને અનલોડ કરવાની મંજૂરી આપે છે. અને તે, અન્ય વસ્તુઓની સાથે, ઑપરેટિંગ સિસ્ટમના પૃષ્ઠ કેશનું નિરીક્ષણ કરવાની મંજૂરી આપે છે, એટલે કે, વહેંચાયેલ બફર્સમાં, પૃષ્ઠ કેશમાં ટેબલ કેટલું કબજે કરે છે, અને ફક્ત તમને ટેબલ પરના લોડનું મૂલ્યાંકન કરવાની મંજૂરી આપે છે.

આગળનું મોડ્યુલ છે pg_stat_kcache. તે સિસ્ટમ કોલનો પણ ઉપયોગ કરે છે getrusage(). અને તે વિનંતીને એક્ઝિક્યુટ કરતા પહેલા અને પછી તેને એક્ઝિક્યુટ કરે છે. અને મેળવેલા આંકડાઓમાં, તે અમને ડિસ્ક I/O પર અમારી વિનંતિનો કેટલો ખર્ચ કર્યો, એટલે કે, ફાઈલ સિસ્ટમ સાથેની કામગીરી અને પ્રોસેસરના વપરાશને જુએ છે તેનો અંદાજ કાઢવાની પરવાનગી આપે છે. જો કે, મોડ્યુલ જુવાન છે (ખે-ખે) અને તેના કામ માટે તેને PostgreSQL 9.4 અને pg_stat_statementsની જરૂર છે, જેનો મેં અગાઉ ઉલ્લેખ કર્યો છે.

• આંકડાઓનો ઉપયોગ કરવાની ક્ષમતા ઉપયોગી છે. તમારે થર્ડ પાર્ટી સોફ્ટવેરની જરૂર નથી. તમે જોઈ શકો છો, જોઈ શકો છો, કંઈક કરી શકો છો, પ્રદર્શન કરી શકો છો.

• આંકડાઓનો ઉપયોગ કરવો સરળ છે, તે સાદો SQL છે. તમે વિનંતી એકત્રિત કરી, તેનું સંકલન કર્યું, તેને મોકલ્યું, તેને જોયું.

• આંકડા પ્રશ્નોના જવાબમાં મદદ કરે છે. જો તમારી પાસે પ્રશ્નો હોય, તો તમે આંકડા તરફ વળો - જુઓ, તારણો દોરો, પરિણામોનું વિશ્લેષણ કરો.

• અને પ્રયોગ. ઘણી બધી વિનંતીઓ, ઘણો ડેટા. તમે હંમેશા કેટલીક હાલની ક્વેરી ઑપ્ટિમાઇઝ કરી શકો છો. તમે વિનંતીનું તમારું પોતાનું સંસ્કરણ બનાવી શકો છો જે તમને મૂળ કરતાં વધુ સારી રીતે અનુકૂળ હોય અને તેનો ઉપયોગ કરી શકો છો.

સંદર્ભો

માન્ય લિંક્સ જે લેખમાં મળી હતી, જેના આધારે, અહેવાલમાં હતી.

લેખક વધુ લખો
https://dataegret.com/news-blog (eng)

સ્ટેટિસ્ટિક્સ કલેક્ટર
https://www.postgresql.org/docs/current/monitoring-stats.html

સિસ્ટમ એડમિનિસ્ટ્રેશન કાર્યો
https://www.postgresql.org/docs/current/functions-admin.html

ફાળો મોડ્યુલો
https://www.postgresql.org/docs/current/pgstatstatements.html
https://www.postgresql.org/docs/current/pgstattuple.html
https://www.postgresql.org/docs/current/pgbuffercache.html
https://github.com/klando/pgfincore
https://github.com/dalibo/pg_stat_kcache

SQL ઉપયોગિતાઓ અને sql કોડ ઉદાહરણો
https://github.com/dataegret/pg-utils

તમારું ધ્યાન બદલ આભાર!

સોર્સ: www.habr.com