એપ્લિકેશન્સમાં લાક્ષણિક ભૂલો જે પોસ્ટગ્રેસ્કીએલમાં બ્લોટ તરફ દોરી જાય છે. આન્દ્રે સાલ્નિકોવ

હું સૂચન કરું છું કે તમે 2016 ની શરૂઆતથી આન્દ્રે સાલ્નિકોવ દ્વારા અહેવાલની ટ્રાન્સક્રિપ્ટ વાંચો "એપ્લિકેશનમાં લાક્ષણિક ભૂલો જે પોસ્ટગ્રેસ્કીએલમાં ફૂલે છે"

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

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

ભૂલો શા માટે કરવામાં આવે છે? તે બે કારણોસર કરવામાં આવે છે: અવ્યવસ્થિત રીતે, કદાચ તે કામ કરશે અને ડેટાબેઝ અને એપ્લિકેશન વચ્ચેના સ્તરે તેમજ ડેટાબેઝમાં જ થતી કેટલીક પદ્ધતિઓની અજ્ઞાનતાને કારણે.

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

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

પ્લેટનો પ્રારંભિક ડેટા: તે એકદમ નાનો છે, 2 MB. ડેટાબેઝ અને ખાસ કરીને સાઇન માટે પ્રતિભાવ સમય પણ ખૂબ જ સારો છે. અને એકદમ સારો લોડ - પ્લેટ અનુસાર પ્રતિ સેકન્ડ 2 ઓપરેશન્સ.

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

અને આ પરિસ્થિતિમાં, આપણે જોઈએ છીએ કે આપણી પાસે ખરેખર એક નાનો સંકેત છે. અનુક્રમણિકા 2 MB પર નાની છે. આ ડાબી બાજુનો પહેલો ગ્રાફ છે.

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

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

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

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

અને હવે આપણી પાસે એક દુર્ઘટના છે. કેટલાક કારણોસર લાંબા સમયથી ભૂલી ગયેલા વ્યવહાર છે. કારણો સામાન્ય રીતે બધા મામૂલી હોય છે:

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

આવી વસ્તુઓ ક્યાં દોરી જાય છે?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

અકસ્માત દરમિયાન શું થયું? આ પ્રક્રિયા ત્યાં કેવી રીતે થઈ?

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

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

વાસ્તવમાં, અમને કામ કરવા માટે ગ્રીન લાઇનની જરૂર છે. પરંતુ આવી સમસ્યા દરમિયાન, તે તારણ આપે છે કે સમગ્ર કોષ્ટકમાં લીલી રેખાઓની ટકાવારી અત્યંત ઓછી છે.

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

આપણા માટે કયા પરિણામો આવી શકે છે?

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

આ હેતુ માટે કાર્યનું ચોક્કસ ચક્ર છે જે હાથ ધરવામાં આવે છે.

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

એકવાર તમને આ કોષ્ટકો મળી જાય, તમારે તેમને સંકુચિત કરવાની જરૂર છે. આ માટે પહેલાથી જ સાધનો છે. અમારી કંપનીમાં અમે ત્રણ ટૂલ્સનો ઉપયોગ કરીએ છીએ. પ્રથમ બિલ્ટ-ઇન VACUUM FULL છે. તે ક્રૂર, કઠોર અને નિર્દય છે, પરંતુ કેટલીકવાર તે ખૂબ જ ઉપયોગી છે. Pg_repack и pg કોમ્પેક્ટેબલ - કોષ્ટકો સંકુચિત કરવા માટે આ તૃતીય-પક્ષ ઉપયોગિતાઓ છે. અને તેઓ ડેટાબેઝને વધુ કાળજીપૂર્વક વર્તે છે.

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

અમે બધું સુધારી લીધા પછી અને બધું બરાબર છે તેની ખાતરી કર્યા પછી, આપણે ભવિષ્યમાં આ પરિસ્થિતિને કેવી રીતે અટકાવવી તે જાણવું જોઈએ:

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

આ આલેખમાં, હું તમને બતાવવા માંગતો હતો કે આ કિસ્સામાં VACUUM FULL સાથેના સાઇનમાંથી પસાર થયા પછી ડેટાબેઝનું ચિહ્ન અને વર્તન કેવી રીતે બદલાયું. આ મારા માટે ઉત્પાદન નથી.

ટેબલનું કદ તરત જ તેની બે મેગાબાઇટ્સની સામાન્ય ઓપરેટિંગ સ્થિતિમાં પાછું આવ્યું. આનાથી સર્વર માટેના સરેરાશ પ્રતિભાવ સમયને બહુ અસર થઈ નથી.

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

અહીં પ્રથમ વાર્તા સમાપ્ત થાય છે. તે સૌથી સામાન્ય છે. અને તે દરેકને થાય છે, ગ્રાહકના અનુભવને ધ્યાનમાં લીધા વિના અને પ્રોગ્રામરો કેટલા લાયક છે. વહેલા કે પછી આ થાય છે.

બીજી વાર્તા, જેમાં અમે લોડનું વિતરણ કરીએ છીએ અને સર્વર સંસાધનોને ઑપ્ટિમાઇઝ કરીએ છીએ

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

અને આ પરિસ્થિતિ કેવી દેખાય છે? ખાસ કરીને આ ગ્રાફ પર, મેં વ્યવહારની અવધિ માટે પ્રતિકૃતિમાંથી વ્યવહારોનો સમયગાળો પણ ઉમેર્યો છે. અન્ય તમામ ગ્રાફ ફક્ત માસ્ટર સર્વરનો સંદર્ભ આપે છે.

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

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

પ્રતિકૃતિ સાથેના સંઘર્ષને કારણે આ અહેવાલો પાછા આવવાનું શરૂ કરે ત્યાં સુધી બધું બરાબર છે. અને તેઓ નિયમિત અંતરાલ પર પાછા ગોળીબાર કરે છે.

અમે ઓનલાઈન જઈએ છીએ અને આ કેમ થઈ રહ્યું છે તે વાંચવાનું શરૂ કરીએ છીએ. અને અમે ઉકેલ શોધીએ છીએ.

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

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

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

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

તે કેવું દેખાશે જો આપણે જાણતા નથી કે હું પહેલા જેની વાત કરી રહ્યો હતો?

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

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

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

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

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

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

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

અમે તે જ રીતે પરિણામોને દૂર કરીએ છીએ:

• અમને ફૂલેલા કોષ્ટકો મળે છે.
• અને અમે તેને સૌથી અનુકૂળ સાધન સાથે સંકુચિત કરીએ છીએ જે અમને અનુકૂળ છે.

બીજી વાર્તા અહીં પૂરી થાય છે. ચાલો ત્રીજી વાર્તા તરફ આગળ વધીએ.

અમારા માટે પણ એકદમ સામાન્ય જેમાં અમે સ્થળાંતર કરીએ છીએ.

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

અહીં તમારી સામે પ્રસ્તુત અપડેટ સાથેનું સ્થળાંતર છે. આ મારા ખાતાના વ્યવહારો હોવાથી, પ્લેટ 15 GB ની હતી. અને અમે દરેક લાઇનને અપડેટ કરી હોવાથી, અમે અપડેટ સાથે કોષ્ટકનું કદ બમણું કર્યું છે, કારણ કે અમે દરેક લાઇન ફરીથી લખી છે.

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

અમે સ્થળાંતર કર્યું અને ફરીથી સમસ્યાઓ આવી.

સ્થળાંતર સફળ થયું, પરંતુ:

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

અને આ ફરીથી ફૂલેલું છે, જે ફરીથી આપણા જીવનને બરબાદ કરે છે.

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

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

અને અહીં મુખ્ય વસ્તુ એ છે કે આવા સ્થળાંતરને યોગ્ય રીતે કેવી રીતે કરવું તે સમજવું. અને તેઓ કરવાની જરૂર છે. અમે આ સ્થળાંતર ખૂબ સતત કરીએ છીએ.

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

અને તે જ સમયે અમને બ્લોટ મળશે નહીં અને પ્રદર્શનની દ્રષ્ટિએ પીડાય નહીં.

અહીં ત્રીજી વાર્તા સમાપ્ત થાય છે.

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

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

અને હવે તે સાધનો વિશે થોડી વધુ વિગત કે જેનો મેં પહેલી વાર્તામાં ઉલ્લેખ કર્યો છે.

બ્લોટ શોધતા પહેલા, તમારે એક્સ્ટેંશન ઇન્સ્ટોલ કરવું આવશ્યક છે pgstattuple.

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

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

અમે શોધી કાઢ્યું કે નકામા ડેટાથી ફૂલેલા કોષ્ટકોને કેવી રીતે ઓળખવા.

હવે બ્લોટ કેવી રીતે ઠીક કરવું તે વિશે:

• જો આપણી પાસે નાની ટેબ્લેટ અને સારી ડિસ્ક હોય, એટલે કે એક ગીગાબાઈટ સુધીના ટેબ્લેટ પર, તો વેક્યુમ ફુલનો ઉપયોગ કરવો તદ્દન શક્ય છે. તે તમારી પાસેથી થોડી સેકંડ માટે ટેબલ પર એક વિશિષ્ટ લોક લેશે અને ઠીક છે, પરંતુ તે બધું જ ઝડપથી અને સખત રીતે કરશે. VACUUM FULL શું કરે છે? તે ટેબલ પર એક વિશિષ્ટ લોક લે છે અને જૂના કોષ્ટકોમાંથી જીવંત પંક્તિઓને નવા કોષ્ટકમાં ફરીથી લખે છે. અને અંતે તે તેમને બદલે છે. તે જૂની ફાઇલોને કાઢી નાખે છે અને જૂની ફાઇલોને નવી સાથે બદલી નાખે છે. પરંતુ તેના કામના સમયગાળા માટે, તે ટેબલ પર એક વિશિષ્ટ લોક લે છે. આનો અર્થ એ છે કે તમે આ કોષ્ટક સાથે કંઈપણ કરી શકતા નથી: ન તો તેને લખો, ન તો તેમાં વાંચો, ન તો તેમાં ફેરફાર કરો. અને VACUUM FULL ને ડેટા લખવા માટે વધારાની ડિસ્ક જગ્યાની જરૂર છે.
• આગામી સાધન pg_repack. તેના સિદ્ધાંતમાં, તે VACUUM FULL જેવું જ છે, કારણ કે તે જૂની ફાઇલોમાંથી ડેટાને નવી ફાઇલોમાં ફરીથી લખે છે અને તેને કોષ્ટકમાં બદલે છે. પરંતુ તે જ સમયે, તે તેના કાર્યની શરૂઆતમાં જ ટેબલ પર વિશિષ્ટ લૉક લેતું નથી, પરંતુ તે ક્ષણે જ લે છે જ્યારે ફાઇલોને બદલવા માટે તેની પાસે પહેલેથી જ તૈયાર ડેટા હોય છે. તેની ડિસ્ક સંસાધન આવશ્યકતાઓ VACUUM FULL જેવી જ છે. તમારે વધારાની ડિસ્ક જગ્યાની જરૂર છે, અને જો તમારી પાસે ટેરાબાઈટ કોષ્ટકો હોય તો આ કેટલીકવાર મહત્વપૂર્ણ છે. અને તે તદ્દન પ્રોસેસર-હંગ્રી છે કારણ કે તે I/O સાથે સક્રિય રીતે કામ કરે છે.
• ત્રીજી ઉપયોગિતા છે pg કોમ્પેક્ટેબલ. તે સંસાધનો સાથે વધુ સાવચેત છે કારણ કે તે સહેજ અલગ સિદ્ધાંતો અનુસાર કાર્ય કરે છે. pgcompacttableનો મુખ્ય વિચાર એ છે કે તે કોષ્ટકમાં અપડેટનો ઉપયોગ કરીને તમામ જીવંત પંક્તિઓને કોષ્ટકની શરૂઆતમાં ખસેડે છે. અને પછી તે આ ટેબલ પર શૂન્યાવકાશ ચલાવે છે, કારણ કે આપણે જાણીએ છીએ કે આપણી પાસે શરૂઆતમાં જીવંત પંક્તિઓ છે અને અંતમાં મૃત પંક્તિઓ છે. અને શૂન્યાવકાશ પોતે જ આ પૂંછડીને કાપી નાખે છે, એટલે કે તેને ઘણી વધારાની ડિસ્ક જગ્યાની જરૂર નથી. અને તે જ સમયે, તે હજુ પણ સંસાધનોની દ્રષ્ટિએ સ્ક્વિઝ કરી શકાય છે.

સાધનો સાથે બધું.

જો તમને બ્લોટ વિષય વધુ અંદર જોવાની દ્રષ્ટિએ રસપ્રદ લાગતો હોય, તો અહીં કેટલીક ઉપયોગી લિંક્સ છે:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - આ મારા સાથીદારનો અહેવાલ છે. તે સામાન્ય છે કે પોસ્ટગ્રેસની જગ્યા તેના કાર્ય અને જીવન દરમિયાન ક્યાં જાય છે. અને બ્લોટ વિશે ડેટાબેઝ સંચાલકો માટે ખૂબ જ વિશાળ અને વિગતવાર તકનીકી ભાગ છે.
• https://github.com/dataegret/pg-utils - આ અમારી રીપોઝીટરીની લિંક છે, જ્યાં અમે ડેટાબેઝની સ્થિતિ તપાસવા માટે ઉપયોગી સ્ક્રિપ્ટોનો સમૂહ સંગ્રહિત કરીએ છીએ. ત્યાં તમે બ્લોટ શોધવા માટે સ્ક્રિપ્ટો શોધી શકો છો.
• ત્રીજો и ચોથું ટૂલ્સની લિંક્સ જે તમને ચિહ્નોને સંકોચવામાં મદદ કરશે.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - આ મારા સાથીદારની પોસ્ટ છે. ત્યાં તે વહીવટકર્તાઓની નજીકના સ્તરે ખૂબ ગંભીરતાપૂર્વક અને તકનીકી રીતે બ્લોટનું વિગતવાર વિશ્લેષણ કરે છે.

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

પ્રશ્નો

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

આ કિસ્સામાં, આ તમારી કંપનીના સંચાલકો માટે એક કાર્ય છે, જરૂરી નથી કે DBA માટે.

હું એડમિનિસ્ટ્રેટર છું.

PostgreSQL પાસે pg_stat_activity નામનો એક વ્યુ છે જે ઝૂલતી ક્વેરીઝ દર્શાવે છે. અને તમે જોઈ શકો છો કે તે ત્યાં કેટલો સમય અટકે છે.

શું મારે દર 5 મિનિટે અંદર આવીને જોવું પડશે?

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

આવું શા માટે થાય છે તેના કોઈ સ્પષ્ટ કારણો છે?

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

રિપોર્ટ માટે આભાર! હું pg_repack ઉપયોગિતા વિશે સ્પષ્ટ કરવા માંગતો હતો. જો તેણી એક વિશિષ્ટ લોક ન કરે, તો પછી...

તેણી એક વિશિષ્ટ લોક કરે છે.

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

ના, તે ટેબલ સાથે સરળતાથી કામ કરે છે, એટલે કે pg_repack પહેલા અસ્તિત્વમાં રહેલી તમામ લાઈવ લાઈનોને સ્થાનાંતરિત કરે છે. સ્વાભાવિક રીતે, ટેબલમાં કોઈ પ્રકારનો પ્રવેશ ત્યાં થાય છે. તે માત્ર આ પોનીટેલ બહાર ફેંકી રહ્યો છે.

એટલે કે, તે ખરેખર અંતે કરે છે?

અંતે, તે આ ફાઇલોને સ્વેપ કરવા માટે એક વિશિષ્ટ લોક લે છે.

શું તે VACUUM FULL કરતાં ઝડપી હશે?

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

નમસ્તે! તમે કાર વેક્યુમના ઓપરેશન વિશે વાત કરી. લાલ, પીળા અને લીલા રેકોર્ડિંગ કોષો સાથેનો ગ્રાફ હતો. એટલે કે, પીળા - તેણે તેમને કાઢી નાખ્યા તરીકે ચિહ્નિત કર્યા. અને પરિણામે, તેમનામાં કંઈક નવું લખી શકાય?

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

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

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

રિપોર્ટ માટે આભાર! શું સમયગાળો મર્યાદિત કરવા માટે સ્ટેટમેન્ટ ટાઈમઆઉટ ક્વેરીઝનો ઉપયોગ કરવો સ્વીકાર્ય છે?

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

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

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

એટલે કે, તે અપડેટ પછી તરત જ બંધ થાય છે?

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

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

સર્વર પરની જગ્યાને યોગ્ય રીતે મોનિટર કરવાની જરૂર છે.

ઉદાહરણ તરીકે, ડીબીએ ચા માટે ગયો, રિસોર્ટમાં હતો, વગેરે.

જ્યારે ફાઇલ સિસ્ટમ બનાવવામાં આવે છે, ત્યારે ઓછામાં ઓછી અમુક પ્રકારની બેકઅપ જગ્યા બનાવવામાં આવે છે જ્યાં ડેટા લખવામાં આવતો નથી.

જો તે સંપૂર્ણપણે શૂન્યથી નીચે હોય તો શું?

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

ત્યાં અન્ય કોઈ સાધનો છે?

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

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

તેઓ તેમને પણ પેક કરે છે.

પરંતુ શૂન્યાવકાશ ઇન્ડેક્સને અસર કરતું નથી?

કેટલાક ઇન્ડેક્સ સાથે કામ કરે છે. ઉદાહરણ તરીકે, pg_rapack, pgcompacttable. શૂન્યાવકાશ અનુક્રમણિકાઓને ફરીથી બનાવે છે અને તેમને અસર કરે છે. VACUUM FULL સાથે દરેક વસ્તુને ઓવરરાઈટ કરવાનો વિચાર છે, એટલે કે તે દરેક સાથે કામ કરે છે.

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

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

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

આ એક સેવા છે ઓકમીટર.

શું આ કોમર્શિયલ પ્રોડક્ટ છે?

હા. આ એક કોમર્શિયલ પ્રોડક્ટ છે.

સોર્સ: www.habr.com