Bug 763072 (GLUSTER-1340)

Summary:	glusterfsd performance reduced after couple of days or XX TB traffic
Product:	[Community] GlusterFS	Reporter:	Matthias <matthias.neder>
Component:	glusterd	Assignee:	tcp
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	high	Docs Contact:
Priority:	low
Version:	3.0.3	CC:	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:
Cloudforms Team:	---	Target Upstream Version:

Description Matthias 2010-08-12 06:48:49 UTC

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 06:20:42 UTC

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-17 02:01:51 UTC

No response from submitter. Closing the bug.

Comment 3 Amar Tumballi 2011-04-13 05:17:20 UTC

Documenting this is not valid, as we our self havn't seen the behavior.