Bug 763206 (GLUSTER-1474)

Summary: Upgrade to 3.0.5 from 2.0.8 degrades self-heal and apache performance significantly
Product: [Community] GlusterFS Reporter: Chida <chida>
Component: coreAssignee: Amar Tumballi <amarts>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: urgent    
Version: 3.0.5CC: gluster-bugs, sac, vijay, vraman
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Chida 2010-08-29 14:55:32 UTC 
some errors in the logs..

E [server-protocol.c:339:protocol_server_reply] protocol/server: frame 8038: failed to submit. op= 14, type= 4
[2010-08-29 13:30:06] E [server-protocol.c:339:protocol_server_reply] protocol/server: frame 8039: failed to submit. op= 25, type= 4
[2010-08-29 13:30:06] E [server-protocol.c:339:protocol_server_reply] protocol/server: frame 8041: failed to submit. op= 14, type= 4
[2010-08-29 13:30:06] E [server-protocol.c:339:protocol_server_reply] protocol/server: frame 8042: failed to submit. op= 25, type= 4
[2010-08-29 13:30:06] E [server-protocol.c:339:protocol_server_reply] protocol/server: frame 8043: failed to submit. op= 25, type= 4
[2010-08-29 13:30:06] E [server-protocol.c:339:protocol_server_reply] protocol/server: frame 8044: failed to submit. op= 14, type= 4
[2010-08-29 13:30:06] E [server-protocol.c:339:protocol_server_reply] protocol/server: frame 8047: failed to submit. op= 14, type= 4
[2010-08-29 13:30:06] E [server-protocol.c:339:protocol_server_reply] protocol/server: frame 8048: failed to submit. op= 14, type= 4
Comment 1 Chida 2010-08-29 16:41:19 UTC 
An upgrade from 3.0.5 from 2.0.8 has worsened apache reponse time on an vaerga from 500ms to 2 seconds. will update logs/volume files soon.
Comment 2 Amar Tumballi 2010-08-31 14:01:56 UTC 
Chida,

I heard this is happening because of some script which was killing the client mount process. Should I still treat this bug as critical severity ? Considering the things have settled down there, we can mark this invalid too.. What do you think?

-Amar
Comment 3 Sachidananda Urs 2010-08-31 14:22:26 UTC 
(In reply to comment #2)
> Chida,
> 
> I heard this is happening because of some script which was killing the client
> mount process. Should I still treat this bug as critical severity ? Considering
> the things have settled down there, we can mark this invalid too.. What do you
> think?
> 

We have another migration over the weekend. Keep this open for a while, I will mark as invalid upon the results over the weekend. If the pattern re-appears I will let the engineering know.
Comment 4 Amar Tumballi 2010-09-13 06:40:55 UTC 
Sacchi, Does this bug hold good now? Is the migration complete ?
Comment 5 Sachidananda Urs 2010-09-13 06:46:27 UTC 
(In reply to comment #4)
> Sacchi, Does this bug hold good now? Is the migration complete ?

Amar, you can close this bug. We figured that the root cause for this might be the inode size in the file system.