Again, if it's doing lots of mmap based IO, it's likely not a big deal. Try getting dtrace to give you useful info? Adrian On 27 July 2011 08:48, Alexander Best <arundel_at_freebsd.org> wrote: > On Mon Jul 25 11, Matthias Andree wrote: >> Am 25.07.2011 09:21, schrieb Alexander Best: >> > On Mon Jul 25 11, Adrian Chadd wrote: >> >> Is it perhaps doing disk IO using mmap? >> > >> > how can i check, whether that's the case or not? >> >> Use truss(1) for instance. >> >> However, unless there are *practical* problems, a high number of page >> faults is not an indication for problems. Although it may sound scary, >> page faults are a feature of the memory management. > > unfortunately truss(1) is crashing chromium :( i opened up a new thread > reagarding this issue on freebsd-current_at_. > > another thing i noticed is the increase in system calls caused by chromium. > let's have a look at hub.freebsd.org: > > uptime = 149 days > > and 'vmstat -s' reports: > > 2168697753 cpu context switches > 2266220366 device interrupts > 2902880931 software interrupts > 3779075897 traps > 902107847 system calls > > now on my box: > > uptime = 2 days > > and 'vmstat -s' reports: > > 1155995386 cpu context switches > 164577882 device interrupts > 189456976 software interrupts > 137007580 traps > 2178434582 system calls > > i ran the following command twice. first time without running chromium and the > second time with chromium running: > > otaku% vmstat -s|grep "system calls"; sleep 1; vmstat -s|grep "system calls" > 2178187850 system calls > 2178189739 system calls > > otaku% vmstat -s|grep "system calls"; sleep 1; vmstat -s|grep "system calls" > 2177998835 system calls > 2178022003 system calls > > so it's 2k/sec vs. 23k/sec!!!! > > cheers. > alex >Received on Wed Jul 27 2011 - 00:28:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:16 UTC