On 20/10/2009 3:01 PM, 黄永卫 wrote: > Thanks for you reply! > Server and the client conect with the same CISCO switch. OK, so they're both on the same local network segment, with the same subnet and IP address range, connected via a single Ethernet switch? Guess it's probably not the network. > This issue always occur after we reboot the server and the postgres service > just become ready statu for serval several minutes. Hang on. You reboot the server? Why? Anyway, let me make sure I understand what you are saying. After you reboot the server, just after the PostgreSQL service has started up, there are several minutes where some (but not all) client connections tend to time out. After that initial problem period, things start to work properly again and the time-outs stop happening. You only have problems shortly after PostgreSQL (and usually the whole server) has been re-started. Right? If so: Could it just be that a rush of reconnecting clients as the server comes up causes so much load that it can't process all the requests before some clients give up? The server would then find, when it got around to answering the client, that the client had since closed the connection, which would result in the errors you see in the log. Try keeping an eye on the number of connected clients, the server load, and the server response time just after it starts up. I'll bet you'll see disk I/O and/or CPU load max out and connections to other services on the same server (say: remote desktop, ssh, file sharing, etc) are also very slow or time out. Do *not* just ping the server; that'll usually remain nearly instant no matter how overloaded the server is. If the problem does turn out to be the server being overloaded: Perhaps you should rate-limit client reconnection attempts? A typical technique that's used is to have clients re-try connections after a random delay. That way, rather than a "thundering herd" of clients all connecting at once, they connect at random intervals over a short period after the server comes back up, so the server only has to process a few connection attempts at once. It's also often a good idea to have that random delay start out quite short, and increase a bit over time. A search for the "thundering herd problem" will tell you a bit more about this, though not in PostgreSQL specific terms. > It is possible that server's performance cause the issue (server is too busy > on that moment) ? Highly likely given the additional information you've now provided. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
