Il 2020-11-27 06:53 Dmitry Antipov ha scritto:
Thanks, it seems you're right. Running local replica 3 volume on 3x1Gb
ramdisks, I'm seeing:
top - 08:44:35 up 1 day, 11:51, 1 user, load average: 2.34, 1.94,
1.00
Tasks: 237 total, 2 running, 235 sleeping, 0 stopped, 0 zombie
%Cpu(s): 38.
Hi Dmitry,
On Thu, Nov 26, 2020 at 10:44 AM Dmitry Antipov wrote:
> BTW, did someone try to profile the brick process? I do, and got this
> for the default replica 3 volume ('perf record -F 2500 -g -p [PID]'):
>
> +3.29% 0.02% glfs_epoll001[kernel.kallsyms] [k]
> entry_SYSCALL_
Top posting as my observations are general and doesn't speak anything
specific to the problem at hand, and what are our ideas to improve it.
Thanks Dmitry for a good thread :-)
I will try to break this into a long answer, but will give short answer for
question.
Does a single thread user app tak
On 11/27/20 11:40 AM, Amar Tumballi wrote:
Now, coming back to the subject, more the CPUs, same test is showing lesser performance gain because your locks would be taking more % bottleneck than in your Laptop. Can you try running the same
test with restricting the number of Cores the glusterfsd
Il 2020-11-27 09:40 Amar Tumballi ha scritto:
Let's get to longer look into performance:
Amar, Xavi, thanks for your input - very appreciated.
However, I found that when facing sync writes (ie: fsync) gluster
performances are very low - too much for a kernel/syscall overhead.
For more info
Hi Ravi,
I'm not sure what was bothering the SHD, but i tried again to restart the
glusterd/glusterfsd's and now the SHD came up. I'm sorry i don't have any
more details about what could have caused the issue.
If you want me to check/search for certain log messages on what could have
caused it, pl
