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@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. =A0Although 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@.
>
> another thing i noticed is the increase in system calls caused by chromiu=
m.
> let's have a look at hub.freebsd.org:
>
> uptime =3D 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 =3D 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 an=
d the
> second time with chromium running:
>
> otaku% vmstat -s|grep "system calls"; sleep 1; vmstat -s|grep "system cal=
ls"
> 2178187850 system calls
> 2178189739 system calls
>
> otaku% vmstat -s|grep "system calls"; sleep 1; vmstat -s|grep "system cal=
ls"
> 2177998835 system calls
> 2178022003 system calls
>
> so it's 2k/sec vs. 23k/sec!!!!
>
> cheers.
> alex
>
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"