Re: [FreeBSD] slony ile replikasyon problemi
İkinci ihtimalde bahsedilen open_idle_transaction_timeout gibi bir değişkenin ileride eklenmesinin düşünüldüğü. Ama atlamış olabileceğiniz asıl nokta burada kullandığınız yazılımın transactionların bir kısmını gereksiz yere idle tuttuğudur. teşekkürler kerem bey, idle in transaction süreçleri sistemimde bir modülün açmış olduğu süreçlerdir. bu süreçlerden birini kill ettiğim zaman diğerleri de otomatik olarak kill oldu ve slony de problem yok gibi görünüyor. fakat modülleri her restart edişimde bu süreçler tekrardan çalışmaya başlıyor. geçici bir çözüm bulduk ama daha optimum çözümlere de açığım. On Fri, 2009-03-27 at 15:11 +0200, Kerem Erciyes wrote: Merhaba, İkinci ihtimalde bahsedilen open_idle_transaction_timeout gibi bir değişkenin ileride eklenmesinin düşünüldüğü. Ama atlamış olabileceğiniz asıl nokta burada kullandığınız yazılımın transactionların bir kısmını gereksiz yere idle tuttuğudur. Kolay Gelsin, Kerem On Thu, Mar 26, 2009 at 10:14 AM, Bayram KARAGOZ bayram.kara...@empatiq.com wrote: merhaba freebsd üzerine kurulu iki farklı sunucudaki iki ayrı postgresql veritabanını slony ile replikasyon işlemine tabii tuttum. replikasyonun yapılmasında herhangi bir problem yok. master sunucuda yaptığım her türlü işlem anında slave veritabanına da ekleniyor. fakat bir süre sonra master sunucuda cpu ve io yükselmesi meydana geliyor. süreçleri incelediğimde master üzerinde çalışan bir processin bu probleme sebep olduğunun farkına vardım. bu süreç sürekli çalıştığı zaman veritabanına yapılan diğer sorgularda takılmalar meydana geliyor ve bazen sorgu cevapları çok geç geliyor. bu süreci sonlandırdığım zaman tekrar sunucu eski haline dönüyor fakat replikasyon işlemi hata veriyor. çalışan süreç aşağıda gösterilmektedir. ön bilgi; master sunucu ip : 10.0.10.231 slave sunucu ip: 10.0.10.232 sippy=# SELECT procpid,client_addr, current_query,query_start from pg_stat_activity where current_query NOT LIKE 'IDLE'; procpid | client_addr | current_query| query_start -+-++--- 84329 | 10.0.10.232 | fetch 100 from LOG; | 2009-03-25 13:05:57.007739+02 yukarıda gösterilen süreç slave sunucu tarafından gönderilen bir istek olduğu client_addr kısmında gösteriliyor. ( fetch 100 from LOG; ) sorgusuyla alakalı slony FAQ da araştırma yaptığımda bu problemin birkaç sebepten kaynaklanabileceği söyleniyor; 14. Some nodes start consistently falling behind I have been running Slony-I on a node for a while, and am seeing system performance suffering. I'm seeing long running queries of the form: fetch 100 from LOG; This can be characteristic of pg_listener (which is the table containing NOTIFY data) having plenty of dead tuples in it. That makes NOTIFY events take a long time, and causes the affected node to gradually fall further and further behind. You quite likely need to do a VACUUM FULL on pg_listener, to vigorously clean it out, and need to vacuum pg_listener really frequently. Once every five minutes would likely be AOK. Slon daemons already vacuum a bunch of tables, and cleanup_thread.c contains a list of tables that are frequently vacuumed automatically. In Slony-I 1.0.2, pg_listener is not included. In 1.0.5 and later, it is regularly vacuumed, so this should cease to be a direct issue. There is, however, still a scenario where this will still bite. Under MVCC, vacuums cannot delete tuples that were made obsolete at any time after the start time of the eldest transaction that is still open. Long running transactions will cause trouble, and should be avoided, even on subscriber nodes. anladığım kadarıyla replikasyon işlemiyle alakalı NOTIFY bilgileri sürekli olarak pg_listener tablosunda tutuluyor ve güncelleniyor. bu sebepten bu tabloda dead tuple lar oluşuyor. bu yüzden bu tablonun yaklaşık 5 dk bir vacuum lanması gerektiği söyleniyor. fakat slony 1.0.5 ve sonra versiyonlar bu işi kendisi yapıyor deniyor. benim kullandığım slony versiyonu 1.2.11. bu yüzden bu ihtimalin olması imkansız gibi görünüyor. sippy=# SELECT * from pg_listener ; relname| listenerpid | notification --+-+-- _ssp_Restart | 85920 |0 (1 row) pkg_version -v |grep slony slony1-1.2.11 needs updating (port has 1.2.15) pkg_version -v |grep postgre* postgresql-client-8.2.5_1 needs updating (port has 8.2.12) postgresql-server-8.2.5_2
Re: [FreeBSD] slony ile replikasyon problemi
modülünüzü gözden geçirerek bu hatayı tekrar etmemesini sağlamanızı tavsiye ederim... On Mon, Mar 30, 2009 at 9:33 AM, Bayram Karagoz karagoz.bay...@gmail.com wrote: İkinci ihtimalde bahsedilen open_idle_transaction_timeout gibi bir değişkenin ileride eklenmesinin düşünüldüğü. Ama atlamış olabileceğiniz asıl nokta burada kullandığınız yazılımın transactionların bir kısmını gereksiz yere idle tuttuğudur. teşekkürler kerem bey, idle in transaction süreçleri sistemimde bir modülün açmış olduğu süreçlerdir. bu süreçlerden birini kill ettiğim zaman diğerleri de otomatik olarak kill oldu ve slony de problem yok gibi görünüyor. fakat modülleri her restart edişimde bu süreçler tekrardan çalışmaya başlıyor. geçici bir çözüm bulduk ama daha optimum çözümlere de açığım. On Fri, 2009-03-27 at 15:11 +0200, Kerem Erciyes wrote: Merhaba, İkinci ihtimalde bahsedilen open_idle_transaction_timeout gibi bir değişkenin ileride eklenmesinin düşünüldüğü. Ama atlamış olabileceğiniz asıl nokta burada kullandığınız yazılımın transactionların bir kısmını gereksiz yere idle tuttuğudur. Kolay Gelsin, Kerem On Thu, Mar 26, 2009 at 10:14 AM, Bayram KARAGOZ bayram.kara...@empatiq.com wrote: merhaba freebsd üzerine kurulu iki farklı sunucudaki iki ayrı postgresql veritabanını slony ile replikasyon işlemine tabii tuttum. replikasyonun yapılmasında herhangi bir problem yok. master sunucuda yaptığım her türlü işlem anında slave veritabanına da ekleniyor. fakat bir süre sonra master sunucuda cpu ve io yükselmesi meydana geliyor. süreçleri incelediğimde master üzerinde çalışan bir processin bu probleme sebep olduğunun farkına vardım. bu süreç sürekli çalıştığı zaman veritabanına yapılan diğer sorgularda takılmalar meydana geliyor ve bazen sorgu cevapları çok geç geliyor. bu süreci sonlandırdığım zaman tekrar sunucu eski haline dönüyor fakat replikasyon işlemi hata veriyor. çalışan süreç aşağıda gösterilmektedir. ön bilgi; master sunucu ip : 10.0.10.231 slave sunucu ip : 10.0.10.232 sippy=# SELECT procpid,client_addr, current_query,query_start from pg_stat_activity where current_query NOT LIKE 'IDLE'; procpid | client_addr | current_query | query_start -+-++--- 84329 | 10.0.10.232 | fetch 100 from LOG; | 2009-03-25 13:05:57.007739+02 yukarıda gösterilen süreç slave sunucu tarafından gönderilen bir istek olduğu client_addr kısmında gösteriliyor. ( fetch 100 from LOG; ) sorgusuyla alakalı slony FAQ da araştırma yaptığımda bu problemin birkaç sebepten kaynaklanabileceği söyleniyor; 14. Some nodes start consistently falling behind I have been running Slony-I on a node for a while, and am seeing system performance suffering. I'm seeing long running queries of the form: fetch 100 from LOG; This can be characteristic of pg_listener (which is the table containing NOTIFY data) having plenty of dead tuples in it. That makes NOTIFY events take a long time, and causes the affected node to gradually fall further and further behind. You quite likely need to do a VACUUM FULL on pg_listener, to vigorously clean it out, and need to vacuum pg_listener really frequently. Once every five minutes would likely be AOK. Slon daemons already vacuum a bunch of tables, and cleanup_thread.c contains a list of tables that are frequently vacuumed automatically. In Slony-I 1.0.2, pg_listener is not included. In 1.0.5 and later, it is regularly vacuumed, so this should cease to be a direct issue. There is, however, still a scenario where this will still bite. Under MVCC, vacuums cannot delete tuples that were made obsolete at any time after the start time of the eldest transaction that is still open. Long running transactions will cause trouble, and should be avoided, even on subscriber nodes. anladığım kadarıyla replikasyon işlemiyle alakalı NOTIFY bilgileri sürekli olarak pg_listener tablosunda tutuluyor ve güncelleniyor. bu sebepten bu tabloda dead tuple lar oluşuyor. bu yüzden bu tablonun yaklaşık 5 dk bir vacuum lanması gerektiği söyleniyor. fakat slony 1.0.5 ve sonra versiyonlar bu işi kendisi yapıyor deniyor. benim kullandığım slony versiyonu 1.2.11. bu yüzden bu ihtimalin olması imkansız gibi görünüyor. sippy=# SELECT * from pg_listener ; relname | listenerpid | notification --+-+-- _ssp_Restart | 85920 | 0 (1 row) pkg_version -v |grep slony slony1-1.2.11 needs updating (port has 1.2.15) pkg_version -v |grep postgre* postgresql-client-8.2.5_1 needs updating (port has 8.2.12) postgresql-server-8.2.5_2 needs updating (port has 8.2.12) 2. neden olarak aşağıdaki ihtimalden bahsediliyor; 25. Replication has been
Re: [FreeBSD] slony ile replikasyon problemi
Merhaba, İkinci ihtimalde bahsedilen open_idle_transaction_timeout gibi bir değişkenin ileride eklenmesinin düşünüldüğü. Ama atlamış olabileceğiniz asıl nokta burada kullandığınız yazılımın transactionların bir kısmını gereksiz yere idle tuttuğudur. Kolay Gelsin, Kerem On Thu, Mar 26, 2009 at 10:14 AM, Bayram KARAGOZ bayram.kara...@empatiq.com wrote: merhaba freebsd üzerine kurulu iki farklı sunucudaki iki ayrı postgresql veritabanını slony ile replikasyon işlemine tabii tuttum. replikasyonun yapılmasında herhangi bir problem yok. master sunucuda yaptığım her türlü işlem anında slave veritabanına da ekleniyor. fakat bir süre sonra master sunucuda cpu ve io yükselmesi meydana geliyor. süreçleri incelediğimde master üzerinde çalışan bir processin bu probleme sebep olduğunun farkına vardım. bu süreç sürekli çalıştığı zaman veritabanına yapılan diğer sorgularda takılmalar meydana geliyor ve bazen sorgu cevapları çok geç geliyor. bu süreci sonlandırdığım zaman tekrar sunucu eski haline dönüyor fakat replikasyon işlemi hata veriyor. çalışan süreç aşağıda gösterilmektedir. ön bilgi; master sunucu ip : 10.0.10.231 slave sunucu ip : 10.0.10.232 sippy=# SELECT procpid,client_addr, current_query,query_start from pg_stat_activity where current_query NOT LIKE 'IDLE'; procpid | client_addr | current_query | query_start -+-++--- 84329 | 10.0.10.232 | fetch 100 from LOG; | 2009-03-25 13:05:57.007739+02 yukarıda gösterilen süreç slave sunucu tarafından gönderilen bir istek olduğu client_addr kısmında gösteriliyor. ( fetch 100 from LOG; ) sorgusuyla alakalı slony FAQ da araştırma yaptığımda bu problemin birkaç sebepten kaynaklanabileceği söyleniyor; 14. Some nodes start consistently falling behind I have been running Slony-I on a node for a while, and am seeing system performance suffering. I'm seeing long running queries of the form: fetch 100 from LOG; This can be characteristic of pg_listener (which is the table containing NOTIFY data) having plenty of dead tuples in it. That makes NOTIFY events take a long time, and causes the affected node to gradually fall further and further behind. You quite likely need to do a VACUUM FULL on pg_listener, to vigorously clean it out, and need to vacuum pg_listener really frequently. Once every five minutes would likely be AOK. Slon daemons already vacuum a bunch of tables, and cleanup_thread.c contains a list of tables that are frequently vacuumed automatically. In Slony-I 1.0.2, pg_listener is not included. In 1.0.5 and later, it is regularly vacuumed, so this should cease to be a direct issue. There is, however, still a scenario where this will still bite. Under MVCC, vacuums cannot delete tuples that were made obsolete at any time after the start time of the eldest transaction that is still open. Long running transactions will cause trouble, and should be avoided, even on subscriber nodes. anladığım kadarıyla replikasyon işlemiyle alakalı NOTIFY bilgileri sürekli olarak pg_listener tablosunda tutuluyor ve güncelleniyor. bu sebepten bu tabloda dead tuple lar oluşuyor. bu yüzden bu tablonun yaklaşık 5 dk bir vacuum lanması gerektiği söyleniyor. fakat slony 1.0.5 ve sonra versiyonlar bu işi kendisi yapıyor deniyor. benim kullandığım slony versiyonu 1.2.11. bu yüzden bu ihtimalin olması imkansız gibi görünüyor. sippy=# SELECT * from pg_listener ; relname | listenerpid | notification --+-+-- _ssp_Restart | 85920 | 0 (1 row) pkg_version -v |grep slony slony1-1.2.11 needs updating (port has 1.2.15) pkg_version -v |grep postgre* postgresql-client-8.2.5_1 needs updating (port has 8.2.12) postgresql-server-8.2.5_2 needs updating (port has 8.2.12) 2. neden olarak aşağıdaki ihtimalden bahsediliyor; 25. Replication has been slowing down, I'm seeing FETCH 100 FROM LOG queries running for a long time, sl_log_1 is growing, and performance is, well, generally getting steadily worse. There are actually a number of possible causes for this sort of thing. There is a question involving similar pathology where the problem is that pg_listener grows because it is not vacuumed. Another proximate cause for this growth is for there to be a connection connected to the node that sits IDLE IN TRANSACTION for a very long time. That open transaction will have multiple negative effects, all of which will adversely affect performance: Vacuums on all tables, including pg_listener,
Re: [FreeBSD] slony ile replikasyon problemi
merhaba freebsd üzerine kurulu iki farklı sunucudaki iki ayrı postgresql veritabanını slony ile replikasyon işlemine tabii tuttum. replikasyonun yapılmasında herhangi bir problem yok. master sunucuda yaptığım her türlü işlem anında slave veritabanına da ekleniyor. fakat bir süre sonra master sunucuda cpu ve io yükselmesi meydana geliyor. süreçleri incelediğimde master üzerinde çalışan bir processin bu probleme sebep olduğunun farkına vardım. bu süreç sürekli çalıştığı zaman veritabanına yapılan diğer sorgularda takılmalar meydana geliyor ve bazen sorgu cevapları çok geç geliyor. bu süreci sonlandırdığım zaman tekrar sunucu eski haline dönüyor fakat replikasyon işlemi hata veriyor. çalışan süreç aşağıda gösterilmektedir. ön bilgi; master sunucu ip : 10.0.10.231 slave sunucu ip: 10.0.10.232 sippy=# SELECT procpid,client_addr, current_query,query_start from pg_stat_activity where current_query NOT LIKE 'IDLE'; procpid | client_addr | current_query| query_start -+-++--- 84329 | 10.0.10.232 | fetch 100 from LOG; | 2009-03-25 13:05:57.007739+02 yukarıda gösterilen süreç slave sunucu tarafından gönderilen bir istek olduğu client_addr kısmında gösteriliyor. ( fetch 100 from LOG; ) sorgusuyla alakalı slony FAQ da araştırma yaptığımda bu problemin birkaç sebepten kaynaklanabileceği söyleniyor; 14. Some nodes start consistently falling behind I have been running Slony-I on a node for a while, and am seeing system performance suffering. I'm seeing long running queries of the form: fetch 100 from LOG; This can be characteristic of pg_listener (which is the table containing NOTIFY data) having plenty of dead tuples in it. That makes NOTIFY events take a long time, and causes the affected node to gradually fall further and further behind. You quite likely need to do a VACUUM FULL on pg_listener, to vigorously clean it out, and need to vacuum pg_listener really frequently. Once every five minutes would likely be AOK. Slon daemons already vacuum a bunch of tables, and cleanup_thread.c contains a list of tables that are frequently vacuumed automatically. In Slony-I 1.0.2, pg_listener is not included. In 1.0.5 and later, it is regularly vacuumed, so this should cease to be a direct issue. There is, however, still a scenario where this will still bite. Under MVCC, vacuums cannot delete tuples that were made obsolete at any time after the start time of the eldest transaction that is still open. Long running transactions will cause trouble, and should be avoided, even on subscriber nodes. anladığım kadarıyla replikasyon işlemiyle alakalı NOTIFY bilgileri sürekli olarak pg_listener tablosunda tutuluyor ve güncelleniyor. bu sebepten bu tabloda dead tuple lar oluşuyor. bu yüzden bu tablonun yaklaşık 5 dk bir vacuum lanması gerektiği söyleniyor. fakat slony 1.0.5 ve sonra versiyonlar bu işi kendisi yapıyor deniyor. benim kullandığım slony versiyonu 1.2.11. bu yüzden bu ihtimalin olması imkansız gibi görünüyor. sippy=# SELECT * from pg_listener ; relname| listenerpid | notification --+-+-- _ssp_Restart | 85920 |0 (1 row) pkg_version -v |grep slony slony1-1.2.11 needs updating (port has 1.2.15) pkg_version -v |grep postgre* postgresql-client-8.2.5_1 needs updating (port has 8.2.12) postgresql-server-8.2.5_2 needs updating (port has 8.2.12) 2. neden olarak aşağıdaki ihtimalden bahsediliyor; 25. Replication has been slowing down, I'm seeing FETCH 100 FROM LOG queries running for a long time, sl_log_1 is growing, and performance is, well, generally getting steadily worse. There are actually a number of possible causes for this sort of thing. There is a question involving similar pathology where the problem is that pg_listener grows because it is not vacuumed. Another proximate cause for this growth is for there to be a connection connected to the node that sits IDLE IN TRANSACTION for a very long time. That open transaction will have multiple negative effects, all of which will adversely affect performance: Vacuums on all tables, including pg_listener, will not clear out dead tuples from before the start of the idle transaction. The cleanup thread will be unable to clean out entries in sl_log_1 and sl_seqlog, with the result that these tables will grow, ceaselessly, until the transaction is closed. You can monitor for this condition inside the database only if the PostgreSQL postgresql.conf parameter stats_command_string is set to true. If that is set, then you may submit the query select * from pg_stat_activity where current_query like '%IDLE% in transaction'; which will find relevant activity. You should also be able to search for
[FreeBSD] slony ile replikasyon problemi
merhaba freebsd üzerine kurulu iki farklı sunucudaki iki ayrı postgresql veritabanını slony ile replikasyon işlemine tabii tuttum. replikasyonun yapılmasında herhangi bir problem yok. master sunucuda yaptığım her türlü işlem anında slave veritabanına da ekleniyor. fakat bir süre sonra master sunucuda cpu ve io yükselmesi meydana geliyor. süreçleri incelediğimde master üzerinde çalışan bir processin bu probleme sebep olduğunun farkına vardım. bu süreç sürekli çalıştığı zaman veritabanına yapılan diğer sorgularda takılmalar meydana geliyor ve bazen sorgu cevapları çok geç geliyor. bu süreci sonlandırdığım zaman tekrar sunucu eski haline dönüyor fakat replikasyon işlemi hata veriyor. çalışan süreç aşağıda gösterilmektedir. ön bilgi; master sunucu ip : 10.0.10.231 slave sunucu ip: 10.0.10.232 sippy=# SELECT procpid,client_addr, current_query,query_start from pg_stat_activity where current_query NOT LIKE 'IDLE'; procpid | client_addr | current_query| query_start -+-++--- 84329 | 10.0.10.232 | fetch 100 from LOG; | 2009-03-25 13:05:57.007739+02 yukarıda gösterilen süreç slave sunucu tarafından gönderilen bir istek olduğu client_addr kısmında gösteriliyor. ( fetch 100 from LOG; ) sorgusuyla alakalı slony FAQ da araştırma yaptığımda bu problemin birkaç sebepten kaynaklanabileceği söyleniyor; 14. Some nodes start consistently falling behind I have been running Slony-I on a node for a while, and am seeing system performance suffering. I'm seeing long running queries of the form: fetch 100 from LOG; This can be characteristic of pg_listener (which is the table containing NOTIFY data) having plenty of dead tuples in it. That makes NOTIFY events take a long time, and causes the affected node to gradually fall further and further behind. You quite likely need to do a VACUUM FULL on pg_listener, to vigorously clean it out, and need to vacuum pg_listener really frequently. Once every five minutes would likely be AOK. Slon daemons already vacuum a bunch of tables, and cleanup_thread.c contains a list of tables that are frequently vacuumed automatically. In Slony-I 1.0.2, pg_listener is not included. In 1.0.5 and later, it is regularly vacuumed, so this should cease to be a direct issue. There is, however, still a scenario where this will still bite. Under MVCC, vacuums cannot delete tuples that were made obsolete at any time after the start time of the eldest transaction that is still open. Long running transactions will cause trouble, and should be avoided, even on subscriber nodes. anladığım kadarıyla replikasyon işlemiyle alakalı NOTIFY bilgileri sürekli olarak pg_listener tablosunda tutuluyor ve güncelleniyor. bu sebepten bu tabloda dead tuple lar oluşuyor. bu yüzden bu tablonun yaklaşık 5 dk bir vacuum lanması gerektiği söyleniyor. fakat slony 1.0.5 ve sonra versiyonlar bu işi kendisi yapıyor deniyor. benim kullandığım slony versiyonu 1.2.11. bu yüzden bu ihtimalin olması imkansız gibi görünüyor. sippy=# SELECT * from pg_listener ; relname| listenerpid | notification --+-+-- _ssp_Restart | 85920 |0 (1 row) pkg_version -v |grep slony slony1-1.2.11 needs updating (port has 1.2.15) pkg_version -v |grep postgre* postgresql-client-8.2.5_1 needs updating (port has 8.2.12) postgresql-server-8.2.5_2 needs updating (port has 8.2.12) 2. neden olarak aşağıdaki ihtimalden bahsediliyor; 25. Replication has been slowing down, I'm seeing FETCH 100 FROM LOG queries running for a long time, sl_log_1 is growing, and performance is, well, generally getting steadily worse. There are actually a number of possible causes for this sort of thing. There is a question involving similar pathology where the problem is that pg_listener grows because it is not vacuumed. Another proximate cause for this growth is for there to be a connection connected to the node that sits IDLE IN TRANSACTION for a very long time. That open transaction will have multiple negative effects, all of which will adversely affect performance: Vacuums on all tables, including pg_listener, will not clear out dead tuples from before the start of the idle transaction. The cleanup thread will be unable to clean out entries in sl_log_1 and sl_seqlog, with the result that these tables will grow, ceaselessly, until the transaction is closed. You can monitor for this condition inside the database only if the PostgreSQL postgresql.conf parameter stats_command_string is set to true. If that is
