Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence
Scott Marlowe <[EMAIL PROTECTED]> wrote: > Well, my guess is that by running under Xen you're already sacrificing > quite a bit of performance, and running it with only 48 Megs of ram is > making it even worse. But if your budget is $100 a year, I guess > you're probably stuck with such a setup. I would see if you can get a > trial Xen at the other hosts with 128M or more of memory and compare. Is running in a 48 MB Xen any different in terms of performance to running on a hardware 48 MB RAM machine? I see that I am not the only one with such requirements, one guy even set up a site listing all VPS providers which host for under 7$ per month: http://www.lowendbox.com/virtual-server-comparison/ You can see that the most you can get for that money is a 128 MB OpenVZ I wonder if running PostgreSQL on OpenVZ is any different to running it on Xen in terms of performance. Oh here is something more: http://vpsempire.com/action.php?do=vpslite 256 MB for 7.45$ per month 512 MB for 11.95$ per month however it doesn't say what is the virtualization software, so don't really know what it is. -- Miernik http://miernik.name/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence
On Wed, Jul 23, 2008 at 2:32 PM, Miernik <[EMAIL PROTECTED]> wrote: > Scott Marlowe <[EMAIL PROTECTED]> wrote: >> won't ever run into. Why such an incredibly limited virtual machine? >> Even my cell phone came with 256 meg built in two years ago. > > Because I don't want to spend too much money on the machine rent, and a > 48 MB RAM Xen is about all I can get with a budget of 100$ per year. > Well, there are a few providers which will give me a 128 MB Xen for that > money, but will the difference in performance be worth the hassle to > switch providers? My current provider gives me almost perfect > relaliability for that 100$ and I don't know how the providers which > give more RAM for the same money perform, maybe they are often down or > something. And spending more then 100$ yearly on this would be really > overkill. My thing runs fine, only a bit slow, but reasonable. I just > want to find out if I could maybe make it better with a little tweaking. > Can I expect it to work at least three times faster on 128 MB RAM? > Getting 256 MB would certainly cost too much. Or maybe there are some > providers which can give me much more performance PostgreSQL server with > at least several GB of storage for well... not more then 50$ per year. > (because I must still rent another server to run and SMTP server and few > other small stuff). > > My DB has several tables with like 10 to 1 million rows each, > running sorts, joins, updates etc on them several times per hour. > About 1 inserts and selects each hour, the whole DB takes 1.5 GB on > disk now, 500 MB dumped. > > If I could shorten the time it takes to run each query by a factor of 3 > that's something worth going for. Well, my guess is that by running under Xen you're already sacrificing quite a bit of performance, and running it with only 48 Megs of ram is making it even worse. But if your budget is $100 a year, I guess you're probably stuck with such a setup. I would see if you can get a trial Xen at the other hosts with 128M or more of memory and compare. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence
Scott Marlowe <[EMAIL PROTECTED]> wrote: > won't ever run into. Why such an incredibly limited virtual machine? > Even my cell phone came with 256 meg built in two years ago. Because I don't want to spend too much money on the machine rent, and a 48 MB RAM Xen is about all I can get with a budget of 100$ per year. Well, there are a few providers which will give me a 128 MB Xen for that money, but will the difference in performance be worth the hassle to switch providers? My current provider gives me almost perfect relaliability for that 100$ and I don't know how the providers which give more RAM for the same money perform, maybe they are often down or something. And spending more then 100$ yearly on this would be really overkill. My thing runs fine, only a bit slow, but reasonable. I just want to find out if I could maybe make it better with a little tweaking. Can I expect it to work at least three times faster on 128 MB RAM? Getting 256 MB would certainly cost too much. Or maybe there are some providers which can give me much more performance PostgreSQL server with at least several GB of storage for well... not more then 50$ per year. (because I must still rent another server to run and SMTP server and few other small stuff). My DB has several tables with like 10 to 1 million rows each, running sorts, joins, updates etc on them several times per hour. About 1 inserts and selects each hour, the whole DB takes 1.5 GB on disk now, 500 MB dumped. If I could shorten the time it takes to run each query by a factor of 3 that's something worth going for. -- Miernik http://miernik.name/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Samsung 32GB SATA SSD tested
On Wed, Jul 23, 2008 at 1:57 PM, Jeffrey Baker <[EMAIL PROTECTED]> wrote: > On Tue, Jul 22, 2008 at 5:32 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote: >> On Tue, Jul 22, 2008 at 6:04 PM, Jeffrey W. Baker <[EMAIL PROTECTED]> wrote: >> >>> Strangely the RAID controller behaves badly on the TPC-B workload. It >>> is faster than disk, but not by a lot, and it's much slower than the >>> other flash configurations. The read/write benchmark did not vary when >>> changing the number of clients between 1 and 8. I suspect this is some >>> kind of problem with Areca's kernel driver or firmware. >> >> Are you still using the 2.6.18 kernel for testing, or have you >> upgraded to something like 2.6.22. I've heard many good things about >> the areca driver in that kernel version. > > These tests are being run with the CentOS 5 kernel, which is 2.6.18. > The ioDrive driver is available for that kernel, and I want to keep > the software constant to get comparable results. > > I put the Samsung SSD in my laptop, which is a Core 2 Duo @ 2.2GHz > with ICH9 SATA port and kernel 2.6.24, and it scored about 525 on R/W > pgbench. >From what I've read the scheduler in 2.6.24 has some performance issues under pgsql. Given that the 2.6.18 kernel driver for the areca card was also mentioned as being questionable, that's the reason I'd asked about the 2.6.22 kernel, which is the one I'll be running in about a month on our big db servers. Ahh, but I won't be running on 32 Gig SATA / Flash drives. :) Wouldn't mind testing an array of 16 or so of them at once though. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Samsung 32GB SATA SSD tested
On Tue, Jul 22, 2008 at 5:32 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote: > On Tue, Jul 22, 2008 at 6:04 PM, Jeffrey W. Baker <[EMAIL PROTECTED]> wrote: > >> Strangely the RAID controller behaves badly on the TPC-B workload. It >> is faster than disk, but not by a lot, and it's much slower than the >> other flash configurations. The read/write benchmark did not vary when >> changing the number of clients between 1 and 8. I suspect this is some >> kind of problem with Areca's kernel driver or firmware. > > Are you still using the 2.6.18 kernel for testing, or have you > upgraded to something like 2.6.22. I've heard many good things about > the areca driver in that kernel version. These tests are being run with the CentOS 5 kernel, which is 2.6.18. The ioDrive driver is available for that kernel, and I want to keep the software constant to get comparable results. I put the Samsung SSD in my laptop, which is a Core 2 Duo @ 2.2GHz with ICH9 SATA port and kernel 2.6.24, and it scored about 525 on R/W pgbench. > This sounds like an interesting development I'll have to keep track > of. In a year or two I might be replacing 16 disk arrays with SSD > drives... I agree, it's definitely an exciting development. I have yet to determine whether the SSDs have good properties for production operations, but I'm learning. -jwb -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence
Miernik wrote: > I have a PostgreSQL database on a very low-resource Xen virtual machine, > 48 MB RAM. When two queries run at the same time, it takes longer to > complete then if run in sequence. Is there perhaps a way to install > something like a query sequencer, which would process queries in a FIFO > manner, one at a time, even if a new query comes before the last one > running is finished, it would not give the new query to the server > before the one running now finishes? That would greatly improve > performance. One idea I just had was to have a connection pooler (say pgpool) and allow only one connection slot. If the pooler is capable to be configured to block new connections until the slot is unused, this would do what you want. (I don't know whether poolers allow you to do this). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence
On Wed, Jul 23, 2008 at 9:21 AM, Miernik <[EMAIL PROTECTED]> wrote: > I have a PostgreSQL database on a very low-resource Xen virtual machine, > 48 MB RAM. When two queries run at the same time, it takes longer to > complete then if run in sequence. Is there perhaps a way to install > something like a query sequencer, which would process queries in a FIFO > manner, one at a time, even if a new query comes before the last one > running is finished, it would not give the new query to the server > before the one running now finishes? That would greatly improve > performance. > > Any tips in general for running PostgreSQL on such low-resource machine? > > I have: > > shared_buffers = 5MB > work_mem = 1024kB > > are these good values, or could perhaps changing something improve it a > bit? Any other parameters to look at? Well, you're basically working on a really limited machine there. I'd set shared buffers up by 1 meg at a time and see if that helps. But you're basically looking at a very narrow problem that most people won't ever run into. Why such an incredibly limited virtual machine? Even my cell phone came with 256 meg built in two years ago. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence
I have a PostgreSQL database on a very low-resource Xen virtual machine, 48 MB RAM. When two queries run at the same time, it takes longer to complete then if run in sequence. Is there perhaps a way to install something like a query sequencer, which would process queries in a FIFO manner, one at a time, even if a new query comes before the last one running is finished, it would not give the new query to the server before the one running now finishes? That would greatly improve performance. Any tips in general for running PostgreSQL on such low-resource machine? I have: shared_buffers = 5MB work_mem = 1024kB are these good values, or could perhaps changing something improve it a bit? Any other parameters to look at? -- Miernik http://miernik.name/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Perl/DBI vs Native
Thanks Guys, this is really useful, especially the pg_service.conf. I have got an app where the connection parameters have to be set in 3 different places I was thinking of writing something myself but now that I know of pg_service.conf, problem solved. Regards, Val --- On Tue, 22/7/08, Jeffrey Baker <[EMAIL PROTECTED]> wrote: > From: Jeffrey Baker <[EMAIL PROTECTED]> > Subject: Re: [PERFORM] Perl/DBI vs Native > To: "Greg Sabino Mullane" <[EMAIL PROTECTED]> > Cc: pgsql-performance@postgresql.org > Date: Tuesday, 22 July, 2008, 9:35 PM > On Tue, Jul 22, 2008 at 9:48 AM, Greg Sabino Mullane > <[EMAIL PROTECTED]> wrote: > >> In case someone is wondering, the way to force DBI > to use unix > >> sockets is by not specifying a host and port in > the connect call. > > > > Actually, the host defaults to the local socket. Using > the port > > may still be needed: if you leave it out, it simply > uses the default > > value (5432) if left out. Thus, for most purposes, > just leaving > > the host out is enough to cause a socket connection on > the default > > port. > > For the further illumination of the historical record, the > best > practice here is probably to use the pg_service.conf file, > which may > or may not live in /etc depending on your operating system. > Then you > can connect in DBI using dbi:Pg:service=whatever, and > change the > definition of "whatever" in pg_service.conf. > This has the same > semantics as PGSERVICE=whatever when using psql. It's > a good idea to > keep these connection details out of your program code. > > -jwb > > -- > Sent via pgsql-performance mailing list > (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
