public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Stefan G. Weichinger" <lists@xunil.at>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Serious stability problems, including freezes
Date: Wed, 03 Jun 2009 09:08:45 +0200	[thread overview]
Message-ID: <4A26217D.5000002@xunil.at> (raw)
In-Reply-To: <200906030844.34437.alexander.puchmayr@linznet.at>

Alexander Puchmayr schrieb:
> Am Mittwoch 03 Juni 2009 schrieb Florian Philipp:
>> Do you have a spare network adapter, maybe an older 100MBit PCI card?
>> Maybe we should rule out a hardware fault on your ethernet chipset first.
>>
> I already thought on this, but the results of my tests dont indicate a 
> hardware fault on the ethernet chipset, because:
> 
> * I can run a ping -f to the machine, it runs for hours without the 
> slightest problem
> * As long as files transfered are small enough (i.e. they fit in the cache 
> buffer on the server) and the server has enough time to write back it to 
> the disk, there is no problem
> * If I explicitly force the ethernet link to be 100FD instead of gigabit, 
> the is also no problem. So I don't expect any error using another 100MBit 
> card.

I would cross-check that anyway just to be sure. Other nic, other
kernel-module ... etc

> For me it looks like as if the following is happening:
> 
> * Memory gets filled up with cached files, no problem so far
> * If no more physical ram is available, the system tries to free some memory 
> internally, e.g. by flushing the caches. 
> *  If releasing cache entries and writing back data to their respective 
> files does not perform fast enough, an internal memory allocation may not 
> succeed, and I see the "page allocation failure" messages, with different 
> processes/kernel threads in the first line.
> * I assume that most of the internal kernel threads don't get a problem in 
> this situation, but there may be some critical parts where we do. Hence, it 
> might just be a matter of probability whether it encounters such a critical 
> part, and the probabilty increases with the MB/s the data is put to the NFS 
> server.

errm, I dunno ... but how would then smaller and slower nfs-servers run
fine? Sounds unlikely to me.

Any special network-settings used? buffer-sizes, MTU, jumbo frames?
switch problems (you seem to have tried auto-negotiation off already).

Stefan



  reply	other threads:[~2009-06-03  7:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02 20:40 [gentoo-user] Serious stability problems, including freezes Alexander Puchmayr
2009-06-03  6:17 ` Florian Philipp
2009-06-03  6:40   ` Stefan G. Weichinger
2009-06-03  6:44   ` Alexander Puchmayr
2009-06-03  7:08     ` Stefan G. Weichinger [this message]
2009-06-03 16:47       ` [gentoo-user] Serious stability problems [SOLVED] Alexander Puchmayr
2009-06-03 17:02         ` Volker Armin Hemmann
2009-06-06  7:48         ` [gentoo-user] Serious stability problems [AGAIN] Alexander Puchmayr
2009-06-03  7:03   ` [gentoo-user] Serious stability problems, including freezes Roy Wright

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A26217D.5000002@xunil.at \
    --to=lists@xunil.at \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox