Re: [FreeBSD] slony ile replikasyon problemi

2009-03-30 Başlik Bayram Karagoz





  
  İ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

2009-03-30 Başlik Kerem Erciyes
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