Re: Postgres filling up hard drive with swap files - Mailing list pgsql-general
From | Bill Moran |
---|---|
Subject | Re: Postgres filling up hard drive with swap files |
Date | |
Msg-id | 20040820160111.00bc2454.wmoran@potentialtech.com Whole thread Raw |
In response to | Re: Postgres filling up hard drive with swap files (Joe Lester <joe_lester@sweetwater.com>) |
Responses |
Re: Postgres filling up hard drive with swap files
|
List | pgsql-general |
Joe Lester <joe_lester@sweetwater.com> wrote: > > If these clients aren't utilizing the database, it might be worthwhile > > to have them disconnect after a period of inactivity, and reconnect > > when > > things get busy again. > > That's a good idea, except in the future, all the clients will be > active most of the time. So, I'd like to get the server to the point > where it can handle 150-200 client connections gracefully. Ahh ... > > I would expect that if you ignore it for a while, eventually it will > > reach an equalibrium. (where it's not increasing the amount of swap in > > use) but it will always hurt performance any time is has to page in or > > out. > > Unfortunately, it does not reach an equilibrium. It just keeps eating > disk space until it's all gone. Well ... I was wrong, and per Tom's post, you've found a problem in Darwin/OS X. > > Please don't wrap machine-generated output ... it makes it VERY > > difficult > > to understand. > > Please forgive me. What do you mean by "wrap machine-generated output". > I would love to oblige. Well, you're wrapping everything. Notice how my part of the conversation above is ugly. It should look like this: > > Please don't wrap machine-generated output ... it makes it VERY difficult > > to understand. In the case of 'machine-generated output', I was specifically talking about top. You sent this: Processes: 231 total, 3 running, 228 sleeping... 300 threads 13:05:16 Load Avg: 0.12, 0.07, 0.02 CPU usage: 6.3% user, 15.9% sys, 77.8% idle SharedLibs: num = 102, resident = 14.0M code, 1.21M data, 2.77M LinkEdit MemRegions: num = 9888, resident = 134M + 7.73M private, 32.9M shared PhysMem: 78.6M wired, 283M active, 141M inactive, 504M used, 7.82M free VM: 12.1G + 70.5M 465206(0) pageins, 1792391(0) pageouts PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 14326 top 19.7% 0:03.13 1 17 26 364K 384K 740K 27.1M ... Notice how incredibly difficult it is to make sense of the top output. Compare with this: Processes: 231 total, 3 running, 228 sleeping... 300 threads 13:05:16 Load Avg: 0.12, 0.07, 0.02 CPU usage: 6.3% user, 15.9% sys, 77.8% idle SharedLibs: num = 102, resident = 14.0M code, 1.21M data, 2.77M LinkEdit MemRegions: num = 9888, resident = 134M + 7.73M private, 32.9M shared PhysMem: 78.6M wired, 283M active, 141M inactive, 504M used, 7.82M free VM: 12.1G + 70.5M 465206(0) pageins, 1792391(0) pageouts PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 14326 top 19.7% 0:03.13 1 17 26 364K 384K 740K 27.1M ... This is usually caused by a setting in your mail client that reads something like "wrap lines at 72 characters" being turned on. You should wrap your text at 72 chars when you're typing, (so it displays readibly on most mail programs) but it's not a good idea to arbitrarily wrap _all_ text in a message to any line length. Doing so usually ends up making a mess of some part of the message. On another note: sorry about leading you in the wrong direction on the problem, but I'm glad Tom was able to isolate it for you. -- Bill Moran Potential Technologies http://www.potentialtech.com
pgsql-general by date: