On Mon, Jul 9, 2018 at 12:46 AM Zhou Choury <cho...@msn.cn> wrote:

> Hi all
>  We mounted cephfs with ceph-fuse on two machines. We found that if a
> process writing a log on node A, while "tail -f" it on node B will quite
> slow, The mds server also complain like:
> > 2018-07-09 15:10:35.516602 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : 2 slow requests, 1 included below; oldest blocked for > 8.421551
> secs
> > 2018-07-09 15:10:35.516608 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : slow request 5.866578 seconds old, received at 2018-07-09
> 15:10:29.649997: client_request(client.3777088:24818 getattr pAsLsXsFs
> #1000008a41e 2018-07-09 15:10:03.842337) currently failed to rdlock, waiting
> > 2018-07-09 15:10:48.517367 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : 2 slow requests, 2 included below; oldest blocked for > 5.860196
> secs
> > 2018-07-09 15:10:48.517373 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : slow request 5.860196 seconds old, received at 2018-07-09
> 15:10:42.657139: client_request(client.3777088:24826 getattr pAsLsXsFs
> #1000008a41e 2018-07-09 15:10:16.843077) currently failed to rdlock, waiting
> > 2018-07-09 15:10:48.517375 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : slow request 5.622276 seconds old, received at 2018-07-09
> 15:10:42.895059: client_request(client.3775872:34689 lookup
> #10000011127/choury-test 2018-07-09 15:10:42.894941) currently failed to
> rdlock, waiting
> > 2018-07-09 15:10:51.517530 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : 2 slow requests, 1 included below; oldest blocked for > 8.622448
> secs
> > 2018-07-09 15:10:51.517536 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : slow request 5.399846 seconds old, received at 2018-07-09
> 15:10:46.117661: client_request(client.3775872:34690 lookup
> #10000011127/choury-test 2018-07-09 15:10:46.117586) currently failed to
> rdlock, waiting
> > 2018-07-09 15:10:53.517640 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : 2 slow requests, 1 included below; oldest blocked for > 10.622560
> secs
> > 2018-07-09 15:10:53.517646 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : slow request 10.622560 seconds old, received at 2018-07-09
> 15:10:42.895059: client_request(client.3775872:34689 lookup
> #10000011127/choury-test 2018-07-09 15:10:42.894941) currently failed to
> rdlock, waiting
> > 2018-07-09 15:10:56.517819 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : 1 slow requests, 1 included below; oldest blocked for > 10.400132
> secs
> > 2018-07-09 15:10:56.517826 7f32fa0c2700  0 log_channel(cluster) log
> [WRN] : slow request 10.400132 seconds old, received at 2018-07-09
> 15:10:46.117661: client_request(client.3775872:34690 lookup
> #10000011127/choury-test 2018-07-09 15:10:46.117586) currently failed to
> rdlock, waiting
>
> We reproduced this problem in the test cluster. there's only two
> processed(on two machines) access the cluster, the writer, and tail.
> The test writer code:
> > #include <stdio.h>
> > #include <string.h>
> > #include <stdlib.h>
> > #include <unistd.h>
> >
> > const char *s =
> "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
> > int main(int argc, char** argv){
> >     FILE *f=fopen(argv[1],"ab+");
> >     if(f==NULL){
> >         printf("cant'to open destination file\n");
> >         return 0;
> >     }
> >     int line = 0;
> >     while(true){
> >         char buff[1024]={0};
> >         for(int i = 0; i< 200; i++){
> >             buff[i] = s[rand()%62];
> >         }
> >         fprintf(f, "%d: %s\n", line++, buff);
> >         fflush(f);
> >         sleep(30);
> >     }
> >     fclose(f);
> >     return 0;
> > }
> The version of ceph is 10.2.10.
> How can I reduce the latency and slow requests?
>

This is inherent to CephFS' strict consistency. When you issue a "tail" on
node B, you are forcing node A to flush out all of its data, then stop
writing, *then* the MDS returns the end of the file data to node B — then
node B drops its "capabilities" on the file and node A gets to start
writing again.

You can do things like this on some NFS systems because they don't actually
guarantee you'll see the results of the latest write to a file, but Ceph
doesn't work that way. There are some programmatic options for reducing
consistency, but I'm not sure any of them can be used to speed up a user
task like you have here.
-Greg


> _______________________________________________
> ceph-users mailing list
> ceph-users@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Reply via email to