ZFS and mem management

George Kontostanos gkontos.mail at gmail.com
Wed Feb 15 10:21:32 UTC 2012


2012/2/15 Pavlo <devgs at ukr.net>:
>
>
>
> Hello.
>
> We have an issue with memory management on FreeBSD and i suspect it is
> related to FS.
> We are using ZFS, here quick stats:
>
>
> zpool status
> pool: disk1
> state: ONLINE
> scan: resilvered 657G in 8h30m with 0 errors on Tue Feb 14 21:17:37 2012
> config:
>
> NAME            STATE     READ WRITE CKSUM
> disk1           ONLINE       0     0     0
> mirror-0      ONLINE       0     0     0
> gpt/disk0   ONLINE       0     0     0
> gpt/disk1   ONLINE       0     0     0
> gpt/disk2     ONLINE       0     0     0
> gpt/disk4     ONLINE       0     0     0
> gpt/disk6     ONLINE       0     0     0
> gpt/disk8     ONLINE       0     0     0
> gpt/disk10    ONLINE       0     0     0
> gpt/disk12    ONLINE       0     0     0
> mirror-7      ONLINE       0     0     0
> gpt/disk14  ONLINE       0     0     0
> gpt/disk15  ONLINE       0     0     0
>
> errors: No known data errors
>
> pool: zroot
> state: ONLINE
> scan: resilvered 34.9G in 0h11m with 0 errors on Tue Feb 14 12:57:52 2012
> config:
>
> NAME          STATE     READ WRITE CKSUM
> zroot         ONLINE       0     0     0
> mirror-0    ONLINE       0     0     0
> gpt/sys0  ONLINE       0     0     0
> gpt/sys1  ONLINE       0     0     0
>
> errors: No known data errors
>
> ------------------------------------------------------------------------
>
> System Memory:
>
> 0.95%    75.61    MiB Active,    0.24%    19.02    MiB Inact
> 18.25%    1.41    GiB Wired,    0.01%    480.00    KiB Cache
> 80.54%    6.24    GiB Free,    0.01%    604.00    KiB Gap
>
> Real Installed:    8.00    GiB
> Real Available:    99.84%    7.99    GiB
> Real Managed:    96.96%    7.74    GiB
>
> Logical Total:    8.00    GiB
> Logical Used:    21.79%    1.74    GiB
> Logical Free:    78.21%    6.26    GiB
>
> Kernel Memory:    1.18    GiB
> Data:    99.05%    1.17    GiB
> Text:    0.95%    11.50    MiB
>
> Kernel Memory Map:    4.39    GiB
> Size:    23.32%    1.02    GiB
> Free:    76.68%    3.37    GiB
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
> ZFS Subsystem Report    Wed Feb 15 10:53:03 2012
> ------------------------------------------------------------------------
>
> System Information:
>
> Kernel Version:    802516 (osreldate)
> Hardware Platform:    amd64
> Processor Architecture:    amd64
>
> ZFS Storage pool Version:    28
> ZFS Filesystem Version:    5
>
> FreeBSD 8.2-STABLE #12: Thu Feb 9 11:35:23 EET 2012 root
> 10:53AM  up 56 mins, 6 users, load averages: 0.00, 0.00, 0.00
>
> ------------------------------------------------------------------------
>
>
>
>
> Background:
> we are using some tool that does indexing of some data and then pushes it
> into  database (currently bdb-5.2). Instances of indexer are running
> continuously one after another. Time of indexing for one instance of
> indexer may vary between  2 seconds and 30 minutes. But mostly it is
> below one minute. There is nothing else running on the machine except
> system stuff and daemons. After several hours of indexing i can see a lot
> of  active memory, it's ok. Then i check the number of vnodes. and it's
> really huge: 300k+ even tho nobody has so many opened files. Reading docs
> and googling i figured that's because of cached pages that reside in
> memory (unmounting of disk causes whole memory to be freed).  Also I
> figured that happens only when I am accessing files via mmap().
>
> Looks like pretty legit behaviour but the issue is:
> This spectacle continues (approximately for 12 hours) unlit indexers
> began to be killed out of swap. As I wrote above I observe a lot of used
> vnodes and like 7GB of active memory. I made a tool that allocates memory
> using malloc() to check what's the limit of available memory that can be
> allocated. It is several megabytes, sometimes more. Unless that tool gets
> killed out of swap as well. So how i can see the issue: for some reason
> after some process had exited normally all mapped pages don't get freed.
> I red about and I agree  that this is reasonable behaviour if we have
> spare memory. But following this logic these pages can be flushed back to
> file at any time when system is under stress conditions. So when I ask
> for a piece of RAM, OS should do that trick and give me what I ask. But
> that's never happens. Those pages are like frozen. Until I unmount disk.
> Even after there is not a single instance of indexer running.
>
> I believe all this is caused by mmap() for sure : BDB uses mmap() for
> accessing databases and we tested indexing with out pushing data to DB.
> Worked shiny. You may suggest that that's something wrong with BDB. But
> we have some more tools of ours that using mmap() as well and the
> behaviour is exact.
>
> Thank you. Paul, Ukraine.
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"

Hi Paul,

Are you using dedup anywhere on that pool?

Also, could you please post the full zfs-stats -a


-- 
George Kontostanos
Aicom telecoms ltd
http://www.aisecure.net


More information about the freebsd-fs mailing list