Bug 1477786 - [GSS]More than 2 smbd processes on a gluster node make application performance dramatically slow down
[GSS]More than 2 smbd processes on a gluster node make application performanc...
Status: ASSIGNED
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: disperse (Show other bugs)
3.2
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Ashish Pandey
nchilaka
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-02 20:35 EDT by liuwei
Modified: 2017-08-24 03:49 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description liuwei 2017-08-02 20:35:31 EDT
Description of problem:

1. Poor performance is related to the number of the client, not the working thread.
   And the number of the client is related to the number of smbd process.
   Poor performance can be reproduce every time when there are more than 2 clients.

     1 node with 8 working threads,         no performance issue.          Number of smbd process is 1
     2 node with 1 working thread for each, Poor performance was observed. Number of smbd process is 2

2. Working thread on client will receive and compress data, and then copy the data to gluster EC volume. Each thread will copy data to an independence directory, 
   So there will not be two or more thread working on same directory, data will copy to separately directory by working thread.

3. Gluster server is running with RHGS 3.2 + samba(gluster_vfs) + CTDB(3 VIPs) on 3 nodes.
   volume is EC(4+2) on 3 nodes, with 2 bricks on each node.
   Client is windows server 2012.

4. Workload is to copy 500 image files, about 200 kb for each.

5. For the working thread method of the client, 

     a. Receive image data and compress it.
     b. Round-robin access the 3 VIPs for connection, 
     c. Copy the image data to an independence directory
     d. (Optional) Move data to another directory when the copy is finished.

   The performance of step c will drop when there are 2 or more clients.

Version-Release number of selected component (if applicable):

RHGS 3.2


How reproducible:

100% reproduced 

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Note You need to log in before you can comment on or make changes to this bug.