* 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.
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
gath
We have the 4 core machine. However, these numbers are taken during a
benchmark, not normal work load. So the output should display the system
being working fully ;)
So its postgres doing a lot of work and you already had a look at the
usrcall for that.
The benchmark just tries to do the que
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
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
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 say
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 which
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
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.
Ye
"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 MyS
10 matches
Mail list logo
