Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

----- Original Message ----- 
From: "Nathan Whitehorn" <nwhitehorn_at_freebsd.org>
To: <freebsd-current_at_freebsd.org>
Sent: Monday, March 18, 2013 1:26 PM
Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots


> On 03/18/13 07:18, Mehmet Erol Sanliturk wrote:
>> On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp <phk_at_phk.freebsd.dk>wrote:
>> 
>>> In message <CAFHbX1KkD7fWP+KZNrSjzCStUM_Smjw7GdKDTo=
>>> DjjMoe5ttGA_at_mail.gmail.com>, Tom Evans writes:
>>>
>>>> You say this, have you actually measured/checked. sysutils/dmidecode
>>>> will interrogate your BIOS and tell us what it thinks is installed in
>>>> each RAM socket. It is not uncommon for RAM to say one thing on the
>>>> outside, and report something completely different to the BIOS.
>>>
>>> I can only second Tom's call for a proper scientific approach to
>>> debugging this issue, rather than just assume that it is the
>>> operating systems fault.
>>>
>>> --
>>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>>> phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
>>> FreeBSD committer       | BSD since 4.3-tahoe
>>> Never attribute to malice what can adequately be explained by incompetence.
>>>
>> 
>> 
>> I am a graduate of Operations Research and Statistics option of a
>> Mathematics department .
>> All of your considerations are considered . It is so much apparent that ,
>> the cause is FreeBSD .
>> 
>> In my previous year message and in its subsequent messages , there are
>> sufficiently detailed information .
>> 
>> 
>> This message is caused from the following fact :
>> 
>> In previous year case , KDE used was a cause , but FluxBox was working fast
>> .
>> Now , I have installed 10.0 current . It does not have KDE in packages . I
>> have installed FluxBox .
>> It is not a few second slow : Many minutes to start Firefox , and activate
>> a menu of it  !
>> 
>> What is the point of measuring milliseconds when the difference is around
>> many minutes ?
>> 
>> PC-BSD installation ( it is a graphical installation after starting X ) is
>> taking many hours to reach 20 percent completion .
>> The same is for GhostBSD : Start it at night , at the next morning , it is
>> likely that it is not finished yet .
>> 
>> 
>> Then : WQhat will be measured ?
>> 
>> Linux installations are around 30 minutes .
>> Starting/Opening menus are instantenous : I do no have chronometer , but
>> everything is within a second .
>> 
>> 
>> Thank you very much .
> 
> The problem is that "slow" doesn't mean anything. An incomplete list of
> things it might be related to:
> 1. Something to do with the way KDE is built (options, system compiler)
> 2. A disk I/O issue
> 3. A memory speed issue
> 4. Some other process using CPU that isn't running on Linux
> 5. A scheduler issue triggered by some property of the machine
> 
> Doing some of these smaller tests will help pin down which of these are
> causing the problem. Without that, there's no possibility to even start
> debugging. Even just running top and seeing whether you are spinning in
> a user thread, in the kernel, or waiting while the slow things are
> happening would be extremely helpful.

Surely you can eliminate all of those and confirm / deny the original
diagnosis by simply installing balanced memory in the machine and checking
to see if the problem goes away?

Could this be an NUMA related issue?

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster_at_multiplay.co.uk.