Bug 763072 (GLUSTER-1340)

Summary: glusterfsd performance reduced after couple of days or XX TB traffic
Product: [Community] GlusterFS Reporter: Matthias <matthias.neder>
Component: glusterdAssignee: tcp
Status: CLOSED WORKSFORME QA Contact:
Severity: high Docs Contact:
Priority: low    
Version: 3.0.3CC: amarts, gluster-bugs, vijay
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: DNR CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Matthias 2010-08-12 02:48:49 EDT
Hi,

i got a strange problem, after a couple of days or XX TB of transfer my glusterfsd performance is dropping down to a 1/4 of the normal bandwith...
This could only be resolved with killing glusterfsd's and restarting them.
On the client side have to do nothing, to fix that issue.
So its on the glusterfsd side.

Its very annoying, because you never know when it happens, because the glusterfsd is running, and serving files but with poor performance.

I need some help to track down that issue. If someone can gimme a hand, that would be nice. It will take several days to reproduce that problem.

Btw. this kind of problem exists since i updated from 2.0.0 to 3.0.3 version.

Kind regards matthias

aka Hawk
Comment 1 tcp 2011-02-10 01:20:42 EST
Are you still hitting the issue? If so, can you please give a description of your setup? Answering the following might help -

- Can you provide the client and server volume files ?
- What is the system configuration of each brick - Memory/CPUs etc ?
- What is the means of data transfer - I mean, you do run "cp" or do you ftp, or do you use a custom script which is doing both reads and writes from/to the volume ?
Comment 2 tcp 2011-03-16 22:01:51 EDT
No response from submitter. Closing the bug.
Comment 3 Amar Tumballi 2011-04-13 01:17:20 EDT
Documenting this is not valid, as we our self havn't seen the behavior.