Re: Pgsql (and mysql) benchmark on T2000/Solaris and some - Mailing list pgsql-performance
From | Jignesh K. Shah |
---|---|
Subject | Re: Pgsql (and mysql) benchmark on T2000/Solaris and some |
Date | |
Msg-id | 4469D173.50406@sun.com Whole thread Raw |
In response to | Pgsql (and mysql) benchmark on T2000/Solaris and some profiling (Arjen van der Meijden <acmmailing@tweakers.net>) |
Responses |
Re: Pgsql (and mysql) benchmark on T2000/Solaris and some
Re: Pgsql (and mysql) benchmark on T2000/Solaris and some |
List | pgsql-performance |
Hi Arjen, Looking at your outputs...of syscall and usrcall it looks like * Spending too much time in semsys .... which means you have too many connections and they are contending to get a lock.. which is potentially the WAL log lock * llseek is high which means you can obviously gain a bit with the right file system/files tuning by caching them right. Have you set the values for Solaris for T2000 tuned for Postgresql? Check out the tunables from the following URL http://www.sun.com/servers/coolthreads/tnb/applications_postgresql.jsp Try specially the /etc/system and postgresql.conf changes and see if it changes/improves your performance. Regards, Jignesh Arjen van der Meijden wrote: > Hi List, > > In the past few weeks we have been developing a read-heavy > mysql-benchmark to have an alternative take at cpu/platform-performance. > Not really to have a look at how fast mysql can be. > > This benchmark runs on mysql 4.1.x, 5.0.x and 5.1.x and is modelled > after our website's production database and the load generated on it is > modelled after a simplified version of our visitor behaviour. > > Long story short, we think the test is a nice example of the relatively > lightweight, read-heavy webapplications out there and therefore decided > to have a go at postgresql as well. > Of course the queries and indexes have been adjusted to (by our > knowledge) best suit postgresql, while maintaining the same output to > the application/interface layer. While the initial structure only got > postgresql at about half the performance of mysql 4.1.x, the current > version of our postgresql-benchmark has quite similar results to mysql > 4.1.x, but both are quite a bit slower than 5.0.x (I think its about > 30-40% faster). > > Since the results from those benchmarks are not yet public (they will be > put together in a story at our website), I won't go into too much > details about this benchmark. > > Currently we're having a look at a Sun T2000 and will be looking at will > be looking at other machines as well in the future. We are running the > sun-release of postgresql 8.1.3 on that T2000 now, but are looking at > compiling the cvs-head version (for its index-root-cache) somewhere this > week. > > My guess is there are a few people on this list who are interested in > some dtrace results taken during our benchmarks on that T2000. > Although my knowledge of both Solaris and Dtrace are very limited, I > already took some samples of the system and user calls. I used Jignesh > Shah's scripts for that: > http://blogs.sun.com/roller/page/jkshah?entry=profiling_postgresql_using_dtrace_on > > > You can find the samples here: > http://achelois.tweakers.net/~acm/pgsql-t2000/syscall.log > http://achelois.tweakers.net/~acm/pgsql-t2000/usrcall.log > > And I also did the memcpy-scripts, here: > http://achelois.tweakers.net/~acm/pgsql-t2000/memcpysize.log > http://achelois.tweakers.net/~acm/pgsql-t2000/memcpystack.log > (this last log is 3.5MB) > > If anyone is interested in some more dtrace results, let me know (and > tell me what commands to run ;-) ). > > Best regards, > > Arjen > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq
pgsql-performance by date: