postgresql 进程出现waiting导致网站响应慢，请问如何解决？

kfping

各位高手帮帮忙？救命！ 这问题已经折腾了我两个月了。
我的网站有时变得很慢，一般在晚上。我估计是并发访问所致，但无从考证。
系统环境：
web服务器，一台2个4核cup8G内存，linux4企业版操作系统，配置双网卡，一个供web外部访问，一个供内部连接数据库。装apache+tomcat+squid作为网站架构。
数据库服务器：一台2个4核cup4G内存，linux4企业版操作系统，装postgres8.1.4版本数据库


网站独立ip日访问量1200左右，数据从google统计来的
网站慢我观察到的现象如下：
1、网站启动squid后，运行一段时间后会出现ping时偶尔丢包现象（ping后频繁出现request time out
）产看squid日志有很多域名解析死循环
2008/01/02 13:30:51| WARNING: Forwarding loop detected for:
Client: 127.0.0.1 http_port: 127.0.0.1:80
。。。。。。
X-Forwarded-For: 116.24.48.200
Cache-Control: max-age=259200
Connection: keep-alive
我的squid.conf配置如下：
http_port 80 transparent
icp_port 0
cache_peer 127.0.0.1 parent 81 0 no-query  originserver
#dd
cache_peer_domain 127.0.0.1
#prefer_direct on
nonhierarchical_direct off
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
cache_mem 512 MB
maximum_object_size 20000 KB
maximum_object_size_in_memory 4096 KB
cache_dir ufs /usr/local/squid/var/cache 10000 16 256
logformat combined %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st "%{Referer}>h" "%{User-Agent}>h" %Ss:%Sh
access_log /usr/local/squid/var/logs/access.log squid
logfile_rotate 0
2、网站慢时，数据库服务器查看进程如下 update waiting，这个waiting已出现网站就响应很慢。
3、我top查看两台服务器的资源状况都很正常，这说明不是服务器资源不够的问题。
问题：
1、从以上squid的配置看，在多人访问会造成ping丢包吗？哪里不妥？
2、数据库出现waiting，如何提高数据库的性能或如何避免waiting？
请各位大虾帮帮忙。。。。。

静候佳音。。。。。谢谢

[ 本帖最后由 kfping 于 2008-1-3 11:04 编辑 ]

arust

是什么类型的网站？客户端经常执行什么类型的操作？
这些问题看起来似乎主要不在于数据库的性能，应该去问问服务器方面的高手，我不是高手，随便说说

kfping

谢谢arust的关注！

客户端经常执行对表的update操作。

请问 数据库出现waiting，如何提高数据库的性能或如何避免waiting？


arust请指点指点。。。。。。。。。。

各位postgresql的大师们也帮忙看看

谢谢

roamvalley

试试vacuumdb 定期清理数据库。
记得使用 -f 参数真实整理数据库，而不是作统计类型的vacuumdb

[ 本帖最后由 roamvalley 于 2008-1-4 13:31 编辑 ]

arust

postgresql大师们一般不会来这种地方，来了也懒得说话

每天1200左右访问量应该不算大，所以我还是觉得数据库方面的问题比较小

kfping

今天有点收获！
丢包的问题解决了。我把过程写出来大家也分享一下。
cat /var/log/meeages //查看系统日志
发现出现
ip_conntrack: table full, dropping packet.

然后我上网找了相关资料
然后我修改了
echo “81920″ > /proc/sys/net/ipv4/ip_conntrack_max
echo “6000″ > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

看到了roamvalley答复后给我很大的启发。

我在linux写了定时脚本用于执行vacuumdb

当我执行vacuumdb时有如下信息：
NOTICE:  number of page slots needed (58016) exceeds max_fsm_pages (40000)
HINT:  Consider increasing the configuration parameter "max_fsm_pages" to a value over 58016.
VACUUM

请问各位大师这是什么意思呢？如何改max_fsm_pages？而这个对我数据库的性能有多大关系呢？

谢谢

roamvalley

1。 数据库在delete和update动作时都是“保留”旧记录，而以追加的方式去添加新记录（包括insert和update)

2。“保留”的旧记录所占用的空间需要被释放，postgresql需要登记这些被占用的空间，便于作vacuumdb时知道哪些空间可以被释放。

3。postgresql是在内存里登记这些信息的，max_fsm_pages就是用于配置这个内存大小。

4。这个配置在postgresql.conf里。

5。但这个参数的配置是要根据你的具体应用来决定它要多大，一个标准的做法是：
先不要作vacuumdb -f，而是用 vacuumdb -vzd databasename
来分析你可能需要多大的空间，最好是在你发现性能瓶颈的时候作。
查看这个分析结果中（很长，看尾部）：
xxx page slots are required to track all free space.
这个xxx就是大致需要max_fsm_pages大小，当然你最好把xxx再放大些。

6。通过这个值的修改可以改善vacuumdb -f的效率

tochu

1. 你跑數據庫的服務器，操作系統關于共享內存的參數是如何設定的，如果可以的話把它貼上來看看

2. postgresql.conf里面的配置，你更改了哪些，最好把這個貼上來看看

3. 跑數據庫的服務器只跑數據庫么？沒有其他應用在上面跑？你網站的內容主要是一些啥操作？select or insert or update or delete or some thing

知道這些信息，或許我可以給你一些建議

kfping

谢谢roamvalley的回复。
写的很清楚，又学会了一点。

也感谢horseman的关注！


1. 你跑數據庫的服務器，操作系統關于共享內存的參數是如何設定的，如果可以的話把它貼上來看看

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296

2. postgresql.conf里面的配置，你更改了哪些，最好把這個貼上來看看
我改了如下：（改后的值）
max_connections = 500

shared_buffers = 4000

#max_fsm_pages = 20000                  # min max_fsm_relations*16, 6 bytes each
#max_fsm_relations = 1000               # min 100, ~70 bytes each
max_fsm_pages=40000

我就改了以上3个地方。

3. 跑數據庫的服務器只跑數據庫么？沒有其他應用在上面跑？你網站的內容主要是一些啥操作？select or insert or update or delete or some thing
我的数据库服务器上没有别的应用，只有数据库。我的网站频繁的操作有（由高到低）select ,update,insert,delete，也就是select和update比较频繁

数据库服务器的配置：2个4核cup，4G内存，linux4企业版操作系

信息如上！

不知horseman有何高见。。。。
也请大师们看看。。。

谢谢各位的指导！

（在线等待中。。。。。。。）

roamvalley

1。打开psql界面，输入以下：
SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
       pg_stat_get_backend_activity(s.backendid) AS current_query
    FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;

2。同时监视你的数据库服务器什么时候发生update waitting状况，一旦发现，立刻记录下它的进程号。

3。迅速把第1步里的语句按回车执行了，查看结果。结果是一个view，结构大致如下：
procpid |                           current_query                           
---------+-------------------------------------------------------------------

   26574 | <IDLE>
   26640 | <IDLE>
   26643 | <IDLE>
   26651 | <IDLE>
   26646 | <IDLE>
   26649 | <IDLE>
   26654 | <IDLE>
   26657 | <IDLE> in transaction
   26659 | <IDLE>
   26674 | <IDLE>
   23623 | <IDLE>
   26824 | SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
         :        pg_stat_get_backend_activity(s.backendid) AS current_query
         :     FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;
   26901 | <IDLE>

（这是我目前开发机器上的结果，没有正在执行的语句，如果有，IDLE就会是SQL语句，最下面的哪条是这个性能执行查询自身的语句）
你把左侧一列的procpid号对应上在第2步中查到的进程号，然后把对应上的current_query  发出来，让大家帮你看看是哪句update语句执行了过长的时间，针对这条update语句再查原因可能会准确些。