[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKPOu+-_X9cc723v_f_BW4CwfHJe_mi=+cbUBP2tZO-kEcyoMA@mail.gmail.com>
Date: Thu, 21 Nov 2024 09:43:37 +0100
From: Max Kellermann <max.kellermann@...os.com>
To: Christoph Hellwig <hch@....de>
Cc: Suren Baghdasaryan <surenb@...gle.com>, Johannes Weiner <hannes@...xchg.org>,
Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org
Subject: Re: Bad psi_group_cpu.tasks[NR_MEMSTALL] counter
On Thu, Nov 21, 2024 at 5:51 AM Christoph Hellwig <hch@....de> wrote:
> Something seems to be going wrong here, though, but the trace below
> doesn't really tell me anything about the workload or file system
> used, and if this is even calling into readahead.
In case you were asking :-) these are web servers (shared webhosting),
running PHP most of the time. The host itself runs on an ext4, but I
don't think the ext4 system partition has anything to do with this.
PHP runs in containers that are erofs, the PHP sources plus
memory-mapped opcache files are in btrfs (read-only snapshot) and the
runtime data is on NFS or Ceph (there have been stalls on both server
types).
My limited experience with Linux MM suggests that this happens during
the page fault of a memory mapped file. PHP processes usually mmap
only files from erofs and btrfs.
The servers are always somewhat under memory pressure; our container
manager keeps as many containers alive as possible and only shuts them
down when the server reaches the memory limit. At any given time,
there are thousands of containers.
Max
Powered by blists - more mailing lists