OS：CentOS 7.6 docker: k8s Server: ARM Redis：3.2.6
when bgsave, it takes 97s to fork log: Apr 18:06:19.029 * 10000 changes in 60 seconds. Saving.. Apr 18:07:56.450 * Background saving started by pid xxx Apr 18:07:56.451 #MASTER timeout: no data nor PING received... Apr 18:07:56.451 # Connection with master lost.]
Someone know why?
Comment From: oranagra
@Liu-Richard i suppose it's some issue with the system configuration, page size or something related. how much memory does the process holds?
Comment From: oranagra
the process holds memory is not big
what does that mean? how much is it? i can guess it's more than 3gb (the COW size).
do you happen to have swap enabled on your system?
let's have a look at the following:
* getconf PAGESIZE
* /proc/<pid>/status
* /proc/<pid>/smaps
* redis-cli -p <port> info all
* /proc/meminfo
* /proc/vmstat
Comment From: Liu-Richard
i can guess it's more than 3gb (the COW size). --yes
mostly betwwen 5GB to 7GB
PAGESIZE:64K
no swapp
I can not login the server to fetch other info now ,thanks
Comment From: oranagra
well, considering the relatively large pages, it's about 80k pages. it shouldn't take that long to copy the page tables. @yossigo maybe you can think of something, otherwise, i'd just say it's probably related to the system in some way, not to redis.
Comment From: yossigo
It seems like it's not consistently slow, in other cases it seems the fork was quick:
[24:S 27 Apr 18:09:10.039 * 10000 changes in 60 seconds. Saving...]
[24:S 27 Apr 18:09:10.043 * Background saving started by pid 329461]
[329461:C 27 Apr 18:09:22.467 * DB saved on disk]
[329461:C 27 Apr 18:09:22.471 * RDB: 3123 MB of memory used by copy-on-write]
I guess it's more likely to be something in the environment. Do note that Redis 3.2.6 is a very old version (5 years old) and may contain many issues fixed with more recent versions, especially on ARM.
Comment From: Liu-Richard
@yossigo I may change a new version to try, which version is better? 5.x or 6.x and how do I get all the issues on ARM？
Comment From: oranagra
@Liu-Richard ideally you should take the latest stable one (6.2.x), but if for some reason you can't then 6.0.x is obviously better than 5.0.x.
Comment From: Liu-Richard
Dose the new version of redis support memory barriers?
Comment From: oranagra
@Liu-Richard what do you mean?
Comment From: Liu-Richard
I didn't see memory barriers in Redis source code, but jemalloc is multipule threads, and ARM is weak memory order, maybe need memory barriers
Comment From: oranagra
redis is mostly single threaded (with the exception of the optional IO threads, modules, and some other minor things). it does use a mutex for threaded modules, and has a few atomic variables (with various ordering concerns), see atomicvar.h. so i'm not sure what you're aiming for.. your original question was about "support" for barriers, now it looks like you're concerned about bugs? do you have any specific question?
p.s. how is this related to this issue? did you eventually figure it out? can it be closed?
Comment From: Liu-Richard
Thanks I'm just skeptical that the issue#9030 has anything to do with the memory barrier. Because ARM cluster( weak memory order) has this problem and x86(strick memory order) cluster does not has this problem