LAN板とソレ以外の日々

某所にてMS_Access用に PostgreSQLで稼動してる箱にpgpool投入ヽ(´ー｀)ノ二重化

ということで、pgpoolを安全側に倒して入れてみたんですが、SEQUENCE多用してたり ODBCドライバの先にあるし…で pgpoolの運用は極度に安全側に倒してｲﾝｽﾄｰﾙ(;´Д`)。案の定ですが「今日は重い！(ﾟДﾟ)」「凄く時間がかかって(ﾟДﾟ)ｽﾄﾚｽですね」と不評ﾊﾞﾝﾊﾞﾝ(;´Д`)
ある程度予想はしてたんですが、こちらで書いてないﾌﾟﾛｸﾞﾗﾑで処理時間3秒～5秒かかってたのが7秒～10秒程度かかるようになってしまったらしく我慢できるﾄｺできないﾄｺの境界を超えてしまったらしく敗北。元に戻して対策を練ることに…こちらで書いてないﾌﾟﾛｸﾞﾗﾑなので流されてるSQLみてindex追加かPostgreSQL自体の最適化くらいしか手が無いかもしれず。

ODBCの向こう側でSQL生成されててｺﾝﾄﾛｰﾙしにくい箇所も多数あるｼｽﾃﾑだし、ｸﾗｲｱﾝﾄ数も40台くらいが同時アクセスと結構ﾏﾄﾓな業務系で、ｻｰﾊﾞのloadavgも そろそろ1.00超えそうな危険水域だったので取りあえず元の状態に戻して・・・と後ろ向き(;´Д`)

SQLのﾁｭｰﾆﾝｸﾞを更に全体的に入れていけばloadavgも小さめに押さえることも出来て、応答時間も速くなるだろうからこの方向で進めるしかないかなあ…と考えつつ mrtg入れて通常業務時の負荷ﾛｸﾞ取ることにして撤退(;´Д`)ﾘﾍﾞﾝｼﾞ予定

あと、pgpoolで接続してる2台のDBの片方のPostgreSQLのプロセスをkillall(pgpoolが接続してるので pg_ctlでは落ちない)かけたところ pgpoolがｸﾗｲｱﾝﾄとの接続を一旦きってしまったらしく、各所でODBCﾄﾞﾗｲﾊﾞのｴﾗｰがﾊﾞﾘﾊﾞﾘ発生して苦情ﾊﾞﾝﾊﾞﾝ(;´Д`)電話が鳴りまくり。このへん設定で色々可能かもしれないので、まあコレも含めて差戻し再検討になったりして(;´Д`)敗走

もう一つの解としては、SEQとか使用している箇所についてだけSELECT時二重化…ですな。こっちだと逆に検索時の負荷分散も可能だし。ということで、まだまだこの話は続くのです(´ー｀)