Re: chromium port causing massive I/O faults

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
>