[GH-ISSUE #2570] Memory spike from 80% to 100% with s3fs processes #1237

Open
opened 2026-03-04 01:52:28 +03:00 by kerem · 16 comments
Owner

Originally created by @Bhagyashreek8 on GitHub (Oct 24, 2024).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2570

Additional Information

Version of s3fs being used (s3fs --version)

Tried on V1.94 and V1.93

sh-4.4# s3fs --version
Amazon Simple Storage Service File System V1.94 (commit:) with OpenSSL
Copyright (C) 2010 Randy Rizun <rrizun@gmail.com>
License GPL2: GNU GPL version 2 <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse or dpkg -s fuse)

Fuse not installed

Kernel information (uname -r)

Linux kube-c0qiuvml0g8hqam57mvg-qcoscluster-qctestd-0000dd83 4.18.0-553.16.1.el8_10.x86_64 https://github.ibm.com/alchemy-containers/customer-tickets/issues/1 SMP Thu Aug 1 04:16:12 EDT 2024 x86_64 x86_64 x86_64 GNU/Linu

GNU/Linux Distribution, if applicable (cat /etc/os-release)

sh-4.4# cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="8.10 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.10"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.10 (Ootpa)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8"
BUG_REPORT_URL="https://issues.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_BUGZILLA_PRODUCT_VERSION=8.10
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.10"

How to run s3fs, if applicable

[x] command line
[] /etc/fstab

root      38008      1 36 Oct21 ?        08:15:12 s3fs qct-openshift-bucket /var/data/kubelet/pods/6ae9dba7-6d3e-4039-888d-3719203f8a73/volumes/ibm~ibmc-s3fs/pvc-95aba19c-8506-471c-bf47-c7e9fadb0e29 -o multireq_max=20 -o use_path_request_style -o passwd_file=/var/lib/ibmc-s3fs/d9db1bd491d43e22e554794ad9bb1f0294232f20b91b52dab7a4bb2071e640a2/passwd -o url=
https://s3.direct.eu-gb.cloud-object-storage.appdomain.cloud/
-o endpoint=eu-gb-standard -o parallel_count=20 -o multipart_size=52 -o dbglevel=warn -o max_stat_cache_size=100000 -o allow_other -o max_background=1000 -o mp_umask=002 -o instance_name=/var/data/kubelet/pods/6ae9dba7-6d3e-4039-888d-3719203f8a73/volumes/ibm~ibmc-s3fs/pvc-95aba19c-8506-471c-bf47-c7e9fadb0e29 -o gid=1000 -o uid=1000 -o retries=5 -o kernel_cache -o default_acl=private
root      38014      1  0 Oct21 ?        00:00:07 s3fs qct-openshift-bucket /var/data/kubelet/pods/6ae9dba7-6d3e-4039-888d-3719203f8a73/volumes/ibm~ibmc-s3fs/pvc-dec3e276-4d2e-469f-858e-1f4b2a2c76d2 -o multireq_max=20 -o use_path_request_style -o passwd_file=/var/lib/ibmc-s3fs/d4ff553e9b08167f0409a8cba03332d0ee40df8c4d1402d926ccfe1847a19e11/passwd -o url=
https://s3.direct.eu-gb.cloud-object-storage.appdomain.cloud/
-o endpoint=eu-gb-standard -o parallel_count=20 -o multipart_size=52 -o dbglevel=warn -o max_stat_cache_size=100000 -o allow_other -o max_background=1000 -o mp_umask=002 -o instance_name=/var/data/kubelet/pods/6ae9dba7-6d3e-4039-888d-3719203f8a73/volumes/ibm~ibmc-s3fs/pvc-dec3e276-4d2e-469f-858e-1f4b2a2c76d2 -o gid=1000 -o uid=1000 -o retries=5 -o kernel_cache -o default_acl=private

s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs)

Details about issue

For one our customers on the kubernetes cluster, s3fs-fuse is spiking the Memory usage to 100% over a period of 2 days time. when s3fs process mounts a bucket from inside a cluster worker node, the worker node memory spikes to 100% by the s3fs process.

[ravindras@bca-ansible-01 ~]$ oc adm top nodes
NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
10.242.0.17     3309m        84%    23311Mi         81%
10.242.128.16   785m         20%    19079Mi         67%
10.242.64.22    692m         17%    22984Mi         80%
[ravindras@bca-ansible-01 ~]$ oc debug node/10.242.0.17
-------------------------------------node/10.242.0.17---------------------------------------
sh-4.4# pid=$(pgrep -u root s3fs); for task in $(ls /proc/$pid/task/); do echo $task;cat /proc/$pid/task/$task/stack;done
13645
[<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse]
[<0>] fuse_dev_read+0x5b/0x90 [fuse]
[<0>] new_sync_read+0x10f/0x160
[<0>] vfs_read+0x91/0x150
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
155112
[<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse]
[<0>] fuse_dev_read+0x5b/0x90 [fuse]
[<0>] new_sync_read+0x10f/0x160
[<0>] vfs_read+0x91/0x150
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
206254
[<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse]
[<0>] fuse_dev_read+0x5b/0x90 [fuse]
[<0>] new_sync_read+0x10f/0x160
[<0>] vfs_read+0x91/0x150
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
21978
[<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse]
[<0>] fuse_dev_read+0x5b/0x90 [fuse]
[<0>] new_sync_read+0x10f/0x160
[<0>] vfs_read+0x91/0x150
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
249272
[<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse]
[<0>] fuse_dev_read+0x5b/0x90 [fuse]
[<0>] new_sync_read+0x10f/0x160
[<0>] vfs_read+0x91/0x150
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
253529
[<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse]
[<0>] fuse_dev_read+0x5b/0x90 [fuse]
[<0>] new_sync_read+0x10f/0x160
[<0>] vfs_read+0x91/0x150
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
44800
cat: /proc/45245/task/44800/stack: No such file or directory
45245
[<0>] futex_wait_queue_me+0xa3/0x100
[<0>] futex_wait+0x11f/0x210
[<0>] do_futex+0x143/0x4e0
[<0>] __x64_sys_futex+0x14e/0x200
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
45247
[<0>] futex_wait_queue_me+0xa3/0x100
[<0>] futex_wait+0x11f/0x210
[<0>] do_futex+0x143/0x4e0
[<0>] __x64_sys_futex+0x14e/0x200
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
45248
[<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse]
[<0>] fuse_dev_read+0x5b/0x90 [fuse]
[<0>] new_sync_read+0x10f/0x160
[<0>] vfs_read+0x91/0x150
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
45262
[<0>] futex_wait_queue_me+0xa3/0x100
[<0>] futex_wait+0x11f/0x210
[<0>] do_futex+0x143/0x4e0
[<0>] __x64_sys_futex+0x14e/0x200
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
45263
[<0>] futex_wait_queue_me+0xa3/0x100
[<0>] futex_wait+0x11f/0x210
[<0>] do_futex+0x143/0x4e0
[<0>] __x64_sys_futex+0x14e/0x200
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
45264
[<0>] futex_wait_queue_me+0xa3/0x100
[<0>] futex_wait+0x11f/0x210
[<0>] do_futex+0x143/0x4e0
[<0>] __x64_sys_futex+0x14e/0x200
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
45265
[<0>] futex_wait_queue_me+0xa3/0x100
[<0>] futex_wait+0x11f/0x210
[<0>] do_futex+0x143/0x4e0
[<0>] __x64_sys_futex+0x14e/0x200
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
45266
[<0>] futex_wait_queue_me+0xa3/0x100
[<0>] futex_wait+0x11f/0x210
[<0>] do_futex+0x143/0x4e0
[<0>] __x64_sys_futex+0x14e/0x200
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
46674
[<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse]
[<0>] fuse_dev_read+0x5b/0x90 [fuse]
[<0>] new_sync_read+0x10f/0x160
[<0>] vfs_read+0x91/0x150
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
53799
[<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse]
[<0>] fuse_dev_read+0x5b/0x90 [fuse]
[<0>] new_sync_read+0x10f/0x160
[<0>] vfs_read+0x91/0x150
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb
sh-4.4#
sh-4.4# ldd /usr/local/bin/s3fs

        linux-vdso.so.1 (0x00007ffff5f71000)

        libfuse.so.2 => /lib64/libfuse.so.2 (0x00007f46c4798000)

        libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f46c4509000)

        libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f46c41a1000)

        libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f46c3cb6000)

        libdl.so.2 => /lib64/libdl.so.2 (0x00007f46c3ab2000)

        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f46c371d000)

        libm.so.6 => /lib64/libm.so.6 (0x00007f46c339b000)

        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f46c3183000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f46c2f63000)

        libc.so.6 => /lib64/libc.so.6 (0x00007f46c2b8d000)

        libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x00007f46c2966000)

        libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f46c2748000)

        libssh.so.4 => /lib64/libssh.so.4 (0x00007f46c24d8000)

        libpsl.so.5 => /lib64/libpsl.so.5 (0x00007f46c22c7000)

        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f46c2033000)

        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f46c1dde000)

        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f46c1af3000)

        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f46c18dc000)

        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f46c16d8000)

        libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007f46c1489000)

        liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f46c1279000)

        libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f46c106c000)

        libz.so.1 => /lib64/libz.so.1 (0x00007f46c0e54000)

        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f46c0c2d000)

        /lib64/ld-linux-x86-64.so.2 (0x00007f46c49d7000)

        libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f46c08ac000)

        librt.so.1 => /lib64/librt.so.1 (0x00007f46c06a4000)

        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f46c0493000)

        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f46c028f000)

        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f46c0077000)

        libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f46bfe59000)

        libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f46bfc38000)

        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f46bfa0d000)

        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f46bf7e4000)

        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f46bf560000)
Originally created by @Bhagyashreek8 on GitHub (Oct 24, 2024). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2570 ### Additional Information #### Version of s3fs being used (`s3fs --version`) Tried on V1.94 and V1.93 ``` sh-4.4# s3fs --version Amazon Simple Storage Service File System V1.94 (commit:) with OpenSSL Copyright (C) 2010 Randy Rizun <rrizun@gmail.com> License GPL2: GNU GPL version 2 <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. ``` #### Version of fuse being used (`pkg-config --modversion fuse`, `rpm -qi fuse` or `dpkg -s fuse`) Fuse not installed #### Kernel information (`uname -r`) Linux kube-c0qiuvml0g8hqam57mvg-qcoscluster-qctestd-0000dd83 4.18.0-553.16.1.el8_10.x86_64 https://github.ibm.com/alchemy-containers/customer-tickets/issues/1 SMP Thu Aug 1 04:16:12 EDT 2024 x86_64 x86_64 x86_64 GNU/Linu #### GNU/Linux Distribution, if applicable (`cat /etc/os-release`) ``` sh-4.4# cat /etc/os-release NAME="Red Hat Enterprise Linux" VERSION="8.10 (Ootpa)" ID="rhel" ID_LIKE="fedora" VERSION_ID="8.10" PLATFORM_ID="platform:el8" PRETTY_NAME="Red Hat Enterprise Linux 8.10 (Ootpa)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:redhat:enterprise_linux:8::baseos" HOME_URL="https://www.redhat.com/" DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8" BUG_REPORT_URL="https://issues.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8" REDHAT_BUGZILLA_PRODUCT_VERSION=8.10 REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux" REDHAT_SUPPORT_PRODUCT_VERSION="8.10" ``` #### How to run s3fs, if applicable <!-- Describe the s3fs "command line" or "/etc/fstab" entry used. --> [x] command line [] /etc/fstab <!-- Executed command line or /etc/fastab entry --> ``` root 38008 1 36 Oct21 ? 08:15:12 s3fs qct-openshift-bucket /var/data/kubelet/pods/6ae9dba7-6d3e-4039-888d-3719203f8a73/volumes/ibm~ibmc-s3fs/pvc-95aba19c-8506-471c-bf47-c7e9fadb0e29 -o multireq_max=20 -o use_path_request_style -o passwd_file=/var/lib/ibmc-s3fs/d9db1bd491d43e22e554794ad9bb1f0294232f20b91b52dab7a4bb2071e640a2/passwd -o url= https://s3.direct.eu-gb.cloud-object-storage.appdomain.cloud/ -o endpoint=eu-gb-standard -o parallel_count=20 -o multipart_size=52 -o dbglevel=warn -o max_stat_cache_size=100000 -o allow_other -o max_background=1000 -o mp_umask=002 -o instance_name=/var/data/kubelet/pods/6ae9dba7-6d3e-4039-888d-3719203f8a73/volumes/ibm~ibmc-s3fs/pvc-95aba19c-8506-471c-bf47-c7e9fadb0e29 -o gid=1000 -o uid=1000 -o retries=5 -o kernel_cache -o default_acl=private root 38014 1 0 Oct21 ? 00:00:07 s3fs qct-openshift-bucket /var/data/kubelet/pods/6ae9dba7-6d3e-4039-888d-3719203f8a73/volumes/ibm~ibmc-s3fs/pvc-dec3e276-4d2e-469f-858e-1f4b2a2c76d2 -o multireq_max=20 -o use_path_request_style -o passwd_file=/var/lib/ibmc-s3fs/d4ff553e9b08167f0409a8cba03332d0ee40df8c4d1402d926ccfe1847a19e11/passwd -o url= https://s3.direct.eu-gb.cloud-object-storage.appdomain.cloud/ -o endpoint=eu-gb-standard -o parallel_count=20 -o multipart_size=52 -o dbglevel=warn -o max_stat_cache_size=100000 -o allow_other -o max_background=1000 -o mp_umask=002 -o instance_name=/var/data/kubelet/pods/6ae9dba7-6d3e-4039-888d-3719203f8a73/volumes/ibm~ibmc-s3fs/pvc-dec3e276-4d2e-469f-858e-1f4b2a2c76d2 -o gid=1000 -o uid=1000 -o retries=5 -o kernel_cache -o default_acl=private ``` #### s3fs syslog messages (`grep s3fs /var/log/syslog`, `journalctl | grep s3fs`, or `s3fs outputs`) <!-- if you execute s3fs with dbglevel, curldbg option, you can get detail debug messages. --> ``` ``` ### Details about issue For one our customers on the kubernetes cluster, s3fs-fuse is spiking the Memory usage to 100% over a period of 2 days time. when s3fs process mounts a bucket from inside a cluster worker node, the worker node memory spikes to 100% by the s3fs process. ``` [ravindras@bca-ansible-01 ~]$ oc adm top nodes NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% 10.242.0.17 3309m 84% 23311Mi 81% 10.242.128.16 785m 20% 19079Mi 67% 10.242.64.22 692m 17% 22984Mi 80% [ravindras@bca-ansible-01 ~]$ oc debug node/10.242.0.17 -------------------------------------node/10.242.0.17--------------------------------------- sh-4.4# pid=$(pgrep -u root s3fs); for task in $(ls /proc/$pid/task/); do echo $task;cat /proc/$pid/task/$task/stack;done 13645 [<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse] [<0>] fuse_dev_read+0x5b/0x90 [fuse] [<0>] new_sync_read+0x10f/0x160 [<0>] vfs_read+0x91/0x150 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 155112 [<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse] [<0>] fuse_dev_read+0x5b/0x90 [fuse] [<0>] new_sync_read+0x10f/0x160 [<0>] vfs_read+0x91/0x150 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 206254 [<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse] [<0>] fuse_dev_read+0x5b/0x90 [fuse] [<0>] new_sync_read+0x10f/0x160 [<0>] vfs_read+0x91/0x150 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 21978 [<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse] [<0>] fuse_dev_read+0x5b/0x90 [fuse] [<0>] new_sync_read+0x10f/0x160 [<0>] vfs_read+0x91/0x150 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 249272 [<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse] [<0>] fuse_dev_read+0x5b/0x90 [fuse] [<0>] new_sync_read+0x10f/0x160 [<0>] vfs_read+0x91/0x150 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 253529 [<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse] [<0>] fuse_dev_read+0x5b/0x90 [fuse] [<0>] new_sync_read+0x10f/0x160 [<0>] vfs_read+0x91/0x150 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 44800 cat: /proc/45245/task/44800/stack: No such file or directory 45245 [<0>] futex_wait_queue_me+0xa3/0x100 [<0>] futex_wait+0x11f/0x210 [<0>] do_futex+0x143/0x4e0 [<0>] __x64_sys_futex+0x14e/0x200 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 45247 [<0>] futex_wait_queue_me+0xa3/0x100 [<0>] futex_wait+0x11f/0x210 [<0>] do_futex+0x143/0x4e0 [<0>] __x64_sys_futex+0x14e/0x200 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 45248 [<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse] [<0>] fuse_dev_read+0x5b/0x90 [fuse] [<0>] new_sync_read+0x10f/0x160 [<0>] vfs_read+0x91/0x150 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 45262 [<0>] futex_wait_queue_me+0xa3/0x100 [<0>] futex_wait+0x11f/0x210 [<0>] do_futex+0x143/0x4e0 [<0>] __x64_sys_futex+0x14e/0x200 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 45263 [<0>] futex_wait_queue_me+0xa3/0x100 [<0>] futex_wait+0x11f/0x210 [<0>] do_futex+0x143/0x4e0 [<0>] __x64_sys_futex+0x14e/0x200 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 45264 [<0>] futex_wait_queue_me+0xa3/0x100 [<0>] futex_wait+0x11f/0x210 [<0>] do_futex+0x143/0x4e0 [<0>] __x64_sys_futex+0x14e/0x200 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 45265 [<0>] futex_wait_queue_me+0xa3/0x100 [<0>] futex_wait+0x11f/0x210 [<0>] do_futex+0x143/0x4e0 [<0>] __x64_sys_futex+0x14e/0x200 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 45266 [<0>] futex_wait_queue_me+0xa3/0x100 [<0>] futex_wait+0x11f/0x210 [<0>] do_futex+0x143/0x4e0 [<0>] __x64_sys_futex+0x14e/0x200 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 46674 [<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse] [<0>] fuse_dev_read+0x5b/0x90 [fuse] [<0>] new_sync_read+0x10f/0x160 [<0>] vfs_read+0x91/0x150 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb 53799 [<0>] fuse_dev_do_read.isra.25+0x875/0x890 [fuse] [<0>] fuse_dev_read+0x5b/0x90 [fuse] [<0>] new_sync_read+0x10f/0x160 [<0>] vfs_read+0x91/0x150 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x66/0xcb sh-4.4# ``` ``` sh-4.4# ldd /usr/local/bin/s3fs linux-vdso.so.1 (0x00007ffff5f71000) libfuse.so.2 => /lib64/libfuse.so.2 (0x00007f46c4798000) libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f46c4509000) libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f46c41a1000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f46c3cb6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f46c3ab2000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f46c371d000) libm.so.6 => /lib64/libm.so.6 (0x00007f46c339b000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f46c3183000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f46c2f63000) libc.so.6 => /lib64/libc.so.6 (0x00007f46c2b8d000) libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x00007f46c2966000) libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f46c2748000) libssh.so.4 => /lib64/libssh.so.4 (0x00007f46c24d8000) libpsl.so.5 => /lib64/libpsl.so.5 (0x00007f46c22c7000) libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f46c2033000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f46c1dde000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f46c1af3000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f46c18dc000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f46c16d8000) libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007f46c1489000) liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f46c1279000) libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f46c106c000) libz.so.1 => /lib64/libz.so.1 (0x00007f46c0e54000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f46c0c2d000) /lib64/ld-linux-x86-64.so.2 (0x00007f46c49d7000) libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f46c08ac000) librt.so.1 => /lib64/librt.so.1 (0x00007f46c06a4000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f46c0493000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f46c028f000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f46c0077000) libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f46bfe59000) libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f46bfc38000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f46bfa0d000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f46bf7e4000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f46bf560000) ```
Author
Owner

@Bhagyashreek8 commented on GitHub (Oct 24, 2024):

strace output for s3fs process
strace-output.txt

<!-- gh-comment-id:2434684029 --> @Bhagyashreek8 commented on GitHub (Oct 24, 2024): strace output for s3fs process [strace-output.txt](https://github.com/user-attachments/files/17504240/strace-output.txt)
Author
Owner

@ggtakec commented on GitHub (Oct 24, 2024):

Does your environment(including your customers) have a container running on a kubernetes worker node host and a corresponding s3fs process running on that worker node host?
(Or is the s3fs process running inside the container?)

I'm sorry I looked at the strace log, but it didn't help us identify the cause.
You've specified the dbglevel=warn option, but is there anything in the output that can solve the problem?
(I think if possible, a dbglevel=info log would help us proceed with the analysis.)

It might be difficult, but is it possible to use s3fs built with the master code(which has some bugs fixed) ?

<!-- gh-comment-id:2435451394 --> @ggtakec commented on GitHub (Oct 24, 2024): Does your environment(including your customers) have a container running on a kubernetes worker node host and a corresponding s3fs process running on that worker node host? (Or is the s3fs process running inside the container?) I'm sorry I looked at the strace log, but it didn't help us identify the cause. You've specified the `dbglevel=warn` option, but is there anything in the output that can solve the problem? (I think if possible, a `dbglevel=info` log would help us proceed with the analysis.) It might be difficult, but is it possible to use s3fs built with the master code(which has some bugs fixed) ?
Author
Owner

@Bhagyashreek8 commented on GitHub (Oct 24, 2024):

Thank you for looking into it @ggtakec

s3fs process runs on the worker node host. A workload consuming the s3fs mount will run as a container (pod/ deployment) on kubernetes worker node. But the s3fs-fuse binary will be sitting on the worker node and s3fs process runs from that worker node host.

I will try to get more logs with dbglevel=info from the customer cluster.

s3fs built with master code would be difficult option as of now as the issue is happening only with the customer production cluster.
And we could not reproduce the issue on our test cluster.

<!-- gh-comment-id:2435632110 --> @Bhagyashreek8 commented on GitHub (Oct 24, 2024): Thank you for looking into it @ggtakec s3fs process runs on the worker node host. A workload consuming the s3fs mount will run as a container (pod/ deployment) on kubernetes worker node. But the s3fs-fuse binary will be sitting on the worker node and s3fs process runs from that worker node host. I will try to get more logs with `dbglevel=info` from the customer cluster. s3fs built with master code would be difficult option as of now as the issue is happening only with the customer production cluster. And we could not reproduce the issue on our test cluster.
Author
Owner

@Bhagyashreek8 commented on GitHub (Nov 5, 2024):

Hi @ggtakec Here are the logs with debug level info. could you please take a look.
10-242-0-4_ibmc-s3fs.zip

<!-- gh-comment-id:2456174083 --> @Bhagyashreek8 commented on GitHub (Nov 5, 2024): Hi @ggtakec Here are the logs with debug level info. could you please take a look. [10-242-0-4_ibmc-s3fs.zip](https://github.com/user-attachments/files/17626682/10-242-0-4_ibmc-s3fs.zip)
Author
Owner

@suresh9494 commented on GitHub (Nov 6, 2024):

Hello Team, We are touching base with you to see if there is any update on this . Thanks

<!-- gh-comment-id:2458736028 --> @suresh9494 commented on GitHub (Nov 6, 2024): Hello Team, We are touching base with you to see if there is any update on this . Thanks
Author
Owner

@sivamtkr1102 commented on GitHub (Nov 10, 2024):

Hello @ggtakec , Request your help to prioritize this case. Thanks.

<!-- gh-comment-id:2466615904 --> @sivamtkr1102 commented on GitHub (Nov 10, 2024): Hello @ggtakec , Request your help to prioritize this case. Thanks.
Author
Owner

@ggtakec commented on GitHub (Nov 10, 2024):

Thanks for the ping.

Regarding this matter, I understand that you start s3fs on the worker node and use the mount point Volume from the container. Is that correct?
Currently, the information you have given me is unable to identify the cause of memory depletion (whether it is a bug or low memory allocation).

However, I was able to find a few interesting articles.
If possible, would it be possible to try removing the kernel_cache option when starting s3fs?
I have seen articles saying that there may be problems if this option is specified in k8s's pod.

<!-- gh-comment-id:2466626850 --> @ggtakec commented on GitHub (Nov 10, 2024): Thanks for the ping. Regarding this matter, I understand that you start s3fs on the worker node and use the mount point Volume from the container. Is that correct? Currently, the information you have given me is unable to identify the cause of memory depletion (whether it is a bug or low memory allocation). However, I was able to find a few interesting articles. If possible, would it be possible to try removing the `kernel_cache` option when starting s3fs? I have seen articles saying that there may be problems if this option is specified in k8s's pod.
Author
Owner

@Bhagyashreek8 commented on GitHub (Nov 11, 2024):

@ggtakec Thanks for the response.
Hi @suresh9494 Could you please ask the customer to try as suggested above.

The cold and vault based storage classes provided by s3fs plugin by default come with kernel-cache set to false. Could you please try using one of these storage classes and redo the above exercise with debug level set to info dbglevel=info and see if that works.

<!-- gh-comment-id:2467929277 --> @Bhagyashreek8 commented on GitHub (Nov 11, 2024): @ggtakec Thanks for the response. Hi @suresh9494 Could you please ask the customer to try as suggested above. The `cold` and `vault` based storage classes provided by s3fs plugin by default come with `kernel-cache` set to false. Could you please try using one of these storage classes and redo the above exercise with debug level set to info `dbglevel=info` and see if that works.
Author
Owner

@Bhagyashreek8 commented on GitHub (Nov 29, 2024):

Hi @ggtakec

Regarding this matter, I understand that you start s3fs on the worker node and use the mount point Volume from the container. Is that correct?
Yes, s3fs running on worker node and the mount path is mount to a container/pod and accessed from there.

If possible, would it be possible to try removing the kernel_cache option when starting s3fs?
Since customer is running production workload, they couldnt try the kernel-cache option.

However, they have mount s3fs to a different cos bucket (which has minimal - around 2 GB of data) and the memory spike has been reduced drastically. It is behaving normal.
The bucket they had mount earlier had > 100GB data with multiple files and folders.

Would there be any issue from s3fs side mounting volume to a cos bucket with huge data and accessing from regularly for read/write?

@suresh9494 - Could you add the info on how frequently customer would hit read/write requests to cos bucket?

<!-- gh-comment-id:2507079751 --> @Bhagyashreek8 commented on GitHub (Nov 29, 2024): Hi @ggtakec > Regarding this matter, I understand that you start s3fs on the worker node and use the mount point Volume from the container. Is that correct? Yes, s3fs running on worker node and the mount path is mount to a container/pod and accessed from there. > If possible, would it be possible to try removing the kernel_cache option when starting s3fs? Since customer is running production workload, they couldnt try the kernel-cache option. However, they have mount s3fs to a different cos bucket (which has minimal - around 2 GB of data) and the memory spike has been reduced drastically. It is behaving normal. The bucket they had mount earlier had > 100GB data with multiple files and folders. Would there be any issue from s3fs side mounting volume to a cos bucket with huge data and accessing from regularly for read/write? @suresh9494 - Could you add the info on how frequently customer would hit read/write requests to cos bucket?
Author
Owner

@tanguofu commented on GitHub (Dec 15, 2024):

can you try with re complie s3fs with jemalloc ? Earlier versions of glibc might not timely release memory back to the operating system

<!-- gh-comment-id:2543890571 --> @tanguofu commented on GitHub (Dec 15, 2024): can you try with re complie s3fs with jemalloc ? Earlier versions of glibc might not timely release memory back to the operating system
Author
Owner

@Bhagyashreek8 commented on GitHub (Dec 23, 2024):

@tanguofu Thank you for the response. Could you confirm the steps followed to build s3fs with jemalloc

./autogen.sh
./configure --with-malloc=jemalloc
make
sudo make install

Is there any other configuration setting required to build s3fs with jemalloc ?

cc @suresh9494

<!-- gh-comment-id:2558934639 --> @Bhagyashreek8 commented on GitHub (Dec 23, 2024): @tanguofu Thank you for the response. Could you confirm the steps followed to build s3fs with jemalloc ``` ./autogen.sh ./configure --with-malloc=jemalloc make sudo make install ``` Is there any other configuration setting required to build s3fs with jemalloc ? cc @suresh9494
Author
Owner

@tanguofu commented on GitHub (Dec 26, 2024):

@Bhagyashreek8
yes, this is dockerfile in my fork https://github.com/tanguofu/s3fs-fuse/blob/master/docker/cosfs-dockerfile#L24

<!-- gh-comment-id:2562367759 --> @tanguofu commented on GitHub (Dec 26, 2024): @Bhagyashreek8 yes, this is dockerfile in my fork https://github.com/tanguofu/s3fs-fuse/blob/master/docker/cosfs-dockerfile#L24
Author
Owner

@Bhagyashreek8 commented on GitHub (Dec 26, 2024):

Hi @tanguofu I tried to build s3fs-fuse with jemalloc, but I have an issue with installing jemalloc on my base image.

To give some background, we build s3fs-fuse on ubi-minimal as base image. And ubi-minimal does not have jemalloc in its microdnf repositories.
One way I can have jemalloc installed is getting the rpm and copying it on to the base image. It requires some effort. So I have couple of questions before trying that -

  1. Can you give some more detail on effectiveness of jemalloc in releasing memory
  2. Is there any ETA for the jemalloc related code from your fork to be merged into s3fs-fuse/master ?
<!-- gh-comment-id:2562928229 --> @Bhagyashreek8 commented on GitHub (Dec 26, 2024): Hi @tanguofu I tried to build s3fs-fuse with jemalloc, but I have an issue with installing jemalloc on my base image. To give some background, we build s3fs-fuse on ubi-minimal as base image. And ubi-minimal does not have jemalloc in its microdnf repositories. One way I can have jemalloc installed is getting the rpm and copying it on to the base image. It requires some effort. So I have couple of questions before trying that - 1. Can you give some more detail on effectiveness of jemalloc in releasing memory 2. Is there any ETA for the jemalloc related code from your fork to be merged into s3fs-fuse/master ?
Author
Owner

@Bhagyashreek8 commented on GitHub (Dec 26, 2024):

Hi @ggtakec Could you please check the above comment on priority - https://github.com/s3fs-fuse/s3fs-fuse/issues/2570#issuecomment-2507079751

<!-- gh-comment-id:2562929548 --> @Bhagyashreek8 commented on GitHub (Dec 26, 2024): Hi @ggtakec Could you please check the above comment on priority - https://github.com/s3fs-fuse/s3fs-fuse/issues/2570#issuecomment-2507079751
Author
Owner

@Bhagyashreek8 commented on GitHub (Jan 9, 2025):

Hi @ggtakec any update on this issue?

<!-- gh-comment-id:2579238064 --> @Bhagyashreek8 commented on GitHub (Jan 9, 2025): Hi @ggtakec any update on this issue?
Author
Owner

@ggtakec commented on GitHub (Jan 18, 2025):

@Bhagyashreek8 Sorry for my late reply.

I still don't understand the cause of this issue.
And I don't think that s3fs memory usage is affected by the bucket (the number of files in it, the file size), so I don't understand the cause of this comment.
(If you specify the use_cache option, the cache file will increase, but since you didn't specify this, it doesn't matter.)

Is it possible to perform a test without specifying the kernel_cache option?
(I am concerned about the impact of this option.)
Also, could you try it without specifying the max_background=1000 option?

These options affect the operation of FUSE itself, not the operation of s3fs, so I would like to eliminate them first and see the results.

<!-- gh-comment-id:2599663900 --> @ggtakec commented on GitHub (Jan 18, 2025): @Bhagyashreek8 Sorry for my late reply. I still don't understand the cause of this issue. And I don't think that s3fs memory usage is affected by the bucket (the number of files in it, the file size), so I don't understand the cause of this [comment](https://github.com/s3fs-fuse/s3fs-fuse/issues/2570#issuecomment-2507079751). _(If you specify the `use_cache` option, the cache file will increase, but since you didn't specify this, it doesn't matter.)_ Is it possible to perform a test without specifying the `kernel_cache` option? _(I am concerned about the impact of this option.)_ Also, could you try it without specifying the `max_background=1000` option? These options affect the operation of FUSE itself, not the operation of s3fs, so I would like to eliminate them first and see the results.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/s3fs-fuse#1237
No description provided.