* Jignesh K. Shah:
* llseek is high which means you can obviously gain a bit with the
right file system/files tuning by caching them right.
It might also make sense to switch from lseek-read/write to
pread/pwrite. It shouldn't be too hard to hack this into the virtual
file descriptor module.
You usertime is way too high for T2000...
If you have a 6 core machine with 24 threads, it says all 24 threads are
reported as being busy with iostat output.
Best way to debug this is use
prstat -amL
(or if you are dumping it in a file prstat -amLc prstat.txt)
and find the pids with high
I have seen MemoryContextSwitchTo taking time before.. However I am not
sure why would it take so much CPU time?
Maybe that function does not work efficiently on Solaris?
Also I donot have much idea about slot_getattr.
Anybody else? (Other option is to use collect -p $pid experiments to
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
Arjen van der Meijden [EMAIL PROTECTED] wrote
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.
Some sort of web query behavior is quite optimized in MySQL. For
Qingqing Zhou wrote:
Arjen van der Meijden [EMAIL PROTECTED] wrote
Some sort of web query behavior is quite optimized in MySQL. For example,
the query below is runing very fast due to the query result cache
implementation in MySQL.
Loop N times
SELECT * FROM A WHERE i = 1;
End loop.
Yeah,
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
Hi Jignesh,
Jignesh K. Shah wrote:
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
Hi Arjen,
Can you send me my colleagues's names in a private email?
One of the drawbacks of the syscall.d script is relative timings and
hence if system CPU usage is very low, it gives the relative weightage
about what portion in that low is associated with what call.. So even if
you have
Hi Jignesh,
The settings from that 'special T2000 dvd' differed from the recommended
settings on the website you provided. But I don't see much difference in
performance with any of the adjustments, it appears to be more or less
the same.
Here are a few iostat lines by the way:
sd0
10 matches
Mail list logo
