Hi Jones, many thanks for your reply. Yepp, I'm using ACL's (Posix ACL's) on filesystem to regulate the access of users for files and directories. Do you mean that this is the "normal" way? These geteuid and getegid system calls are so slow? On the previous system (Debian Wheezy, Samba 3) I've also used ACL's, but there were much faster than this... What should be the solution? Do you have any idea? Thanks, Ervin On Mon, Apr 20, 2015 at 10:48:37AM +0800, Jones Syue wrote:> Hello Ervin, > ? > > On Sat, Apr 18, 2015 at 5:01 PM, Ervin Heged?s <airween at gmail.com> wrote: > > > > > Why faster the Samba for users, who listed in "admin users" in > > smb.conf? > > > > Hmm looks like earlier return for users with root permission, > so admin users would not go through SMB_VFS_GET_NT_ACL(), > which takes more time on permission checking.[1] > > Non-admin users would go through SMB_VFS_GET_NT_ACL(), > and finally would reach getegid() and geteuid().[2] > > Hence strace said the top 2 records are getegid() and geteuid(). > > > [1] code snippet: > NTSTATUS smbd_check_access_rights(struct connection_struct *conn, > ... > if (!use_privs && get_current_uid(conn) == (uid_t)0) { > /* I'm sorry sir, I didn't know you were root... */ > DEBUG(10,("smbd_check_access_rights: root override " > "on %s. Granting 0x%x\n", > smb_fname_str_dbg(smb_fname), > (unsigned int)access_mask )); > return NT_STATUS_OK; > } > ... > status = SMB_VFS_GET_NT_ACL(conn, smb_fname->base_name, > (SECINFO_OWNER | > SECINFO_GROUP | > SECINFO_DACL), talloc_tos(), &sd); > > ?[2]? perf top call graph: > > ?1.49% libc-2.6.1.so [.] __geteuid > | > --- __geteuid > uwrap_geteuid > assert_uid > set_unix_security_ctx > set_sec_ctx > set_root_sec_ctx > smbd_become_root > legacy_gid_to_sid > gid_to_sid > create_file_sids > posix_get_nt_acl_common > posix_get_nt_acl > vfswrap_get_nt_acl > smb_vfs_call_get_nt_acl > smbd_check_access_rights > > 1.22% libc-2.6.1.so [.] __getegid > | > --- __getegid > uwrap_getegid > assert_gid > set_unix_security_ctx > set_sec_ctx > set_root_sec_ctx > smbd_become_root > become_root > pdb_default_uid_to_sid > pdb_uid_to_sid > legacy_uid_to_sid > uid_to_sid > create_file_sids > posix_get_nt_acl_common > posix_get_nt_acl > vfswrap_get_nt_acl > smb_vfs_call_get_nt_acl > smbd_check_access_rights? > > -- > Regards, > Jones Syue | ??? > *QNAP* Systems,Inc. <http://www.qnap.com/> > ?
Hello Ervin, ?> Do you mean that this is the "normal" way? These geteuid and > getegid system calls are so slow? >>> ?% time seconds usecs/call calls errors syscall?>> ? ------ ----------- ----------- --------- --------- ---------------- ?>> ? 15.68 15.894980 4 4398791 getegid>> 15.57 15.783699 4 4398801 geteuid?Hmm yeap ?as earlier mentioned, both system calls are top 2 and more than 30% during compiling. ?As? 'perf top' call graph depicted, gete{uid, gid} will go through samba stacks, glibc, and syscalls to reach kernel finally, this critical path spent time on stack push-pop, context switches, etc. On the previous system (Debian Wheezy, Samba 3) I've also used> ACL's, but there were much faster than this... > > What should be the solution? Do you have any idea? >Hmm my guess the difference is made by in-memory cache lookup[1], samba-3 with it. But samba-4 without it, so non-admin users reach gete{uid, gid} heavily, admin users could ease this pain because earlier return by get_current_uid(). Here is my test to imply this guess, test-bench is uploading 5,000 files and each one is 1MB. Case A) samba-3.6.25 without modification, strace show nothing through gete{uid, gid}, and spent 85 seconds on uploading. Case B) Remove cache lookup from samba-3.6.25, strace show syscalls to gete{uid, gid}, and spent 100 seconds on uploading. [1] https://git.samba.org/?p=samba.git;a=commit;h=c89affbd8da230cae6df25558fe621510690392c [2] % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 57.39 0.275347 1 510297 poll 10.68 0.051248 1 80000 pwrite64 8.63 0.041410 0 840458 readv 4.26 0.020430 0 1555919 gettimeofday 3.53 0.016950 0 2513576 fcntl64 2.96 0.014199 0 165051 writev 1.42 0.006830 0 1520391 geteuid32 1.38 0.006627 0 1520387 getegid32 0.99 0.004772 0 165850 close 0.97 0.004667 0 421195 1 stat64 0.83 0.003990 0 640165 setreuid32 0.74 0.003569 0 165050 open 0.70 0.003370 0 640165 setregid32 0.64 0.003071 0 251161 140043 getxattr 0.63 0.003002 0 480123 setgroups32 0.51 0.002443 0 80019 fchmod 0.47 0.002242 0 160039 munmap 0.45 0.002182 0 160038 160038 lstat64 0.40 0.001905 0 320076 alarm 0.38 0.001800 0 400095 getgroups32 0.36 0.001727 0 320076 rt_sigaction 0.34 0.001634 0 10000 ftruncate64 0.33 0.001595 0 160039 mmap2 0.27 0.001287 0 80020 read 0.20 0.000963 0 190058 fstat64 0.17 0.000814 0 160040 _llseek 0.16 0.000786 0 25001 setxattr 0.09 0.000423 0 15000 SYS_320 0.05 0.000220 4 54 getdents64 0.04 0.000214 0 30004 clock_gettime 0.01 0.000038 0 800 800 connect 0.01 0.000032 0 5000 flock 0.00 0.000008 0 800 socket 0.00 0.000000 0 1 restart_syscall 0.00 0.000000 0 1 chdir 0.00 0.000000 0 13 time 0.00 0.000000 0 10 lseek 0.00 0.000000 0 1 ioctl 0.00 0.000000 0 2 umask 0.00 0.000000 0 1 dup2 ------ ----------- ----------- --------- --------- ---------------- 100.00 0.479795 13586976 300882 total [3] ?% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 57.88 0.165190 0 504915 poll 15.10 0.043100 1 80000 pwrite64 12.69 0.036217 0 835020 readv 6.15 0.017556 0 1539769 gettimeofday 4.07 0.011628 0 165038 writev 1.20 0.003428 0 421171 2 stat64 1.13 0.003222 0 432338 fcntl64 0.75 0.002147 0 251161 140043 getxattr 0.29 0.000830 0 5015 close 0.23 0.000657 0 10000 ftruncate64 0.18 0.000508 0 25001 setxattr 0.14 0.000410 0 15000 SYS_320 0.07 0.000197 0 30023 fstat64 0.06 0.000179 0 30005 clock_gettime 0.04 0.000117 0 5015 open 0.01 0.000036 0 5000 flock 0.00 0.000000 0 1 restart_syscall 0.00 0.000000 0 2 read 0.00 0.000000 0 3 time 0.00 0.000000 0 10 lseek 0.00 0.000000 0 4 alarm 0.00 0.000000 0 3 brk 0.00 0.000000 0 1 ioctl 0.00 0.000000 0 4 umask 0.00 0.000000 0 2 dup2 0.00 0.000000 0 3 munmap 0.00 0.000000 0 1 fchmod 0.00 0.000000 0 4 _llseek 0.00 0.000000 0 4 rt_sigaction 0.00 0.000000 0 3 mmap2 0.00 0.000000 0 2 2 lstat64 0.00 0.000000 0 46 geteuid32 0.00 0.000000 0 41 getegid32 0.00 0.000000 0 19 setreuid32 0.00 0.000000 0 19 setregid32 0.00 0.000000 0 5 getgroups32 0.00 0.000000 0 14 setgroups32 0.00 0.000000 0 54 getdents64 ------ ----------- ----------- --------- --------- ---------------- 100.00 0.285422 4354716 140047 total ? -- Regards, Jones Syue | ??? *QNAP* Systems,Inc. <http://www.qnap.com/>
For clear:? ?> ? > Case A) samba-3.6.25 without modification,? > ?% time seconds usecs/call calls errors syscall > ------ ----------- ----------- --------- --------- ---------------- > 57.88 0.165190 0 504915 poll > 15.10 0.043100 1 80000 pwrite64 > 12.69 0.036217 0 835020 readv > 6.15 0.017556 0 1539769 gettimeofday > 4.07 0.011628 0 165038 writev > 1.20 0.003428 0 421171 2 stat64 > 1.13 0.003222 0 432338 fcntl64 > 0.75 0.002147 0 251161 140043 getxattr > 0.29 0.000830 0 5015 close > 0.23 0.000657 0 10000 ftruncate64 > 0.18 0.000508 0 25001 setxattr > 0.14 0.000410 0 15000 SYS_320 > 0.07 0.000197 0 30023 fstat64 > 0.06 0.000179 0 30005 clock_gettime > 0.04 0.000117 0 5015 open > 0.01 0.000036 0 5000 flock > 0.00 0.000000 0 1 restart_syscall > 0.00 0.000000 0 2 read > 0.00 0.000000 0 3 time > 0.00 0.000000 0 10 lseek > 0.00 0.000000 0 4 alarm > 0.00 0.000000 0 3 brk > 0.00 0.000000 0 1 ioctl > 0.00 0.000000 0 4 umask > 0.00 0.000000 0 2 dup2 > 0.00 0.000000 0 3 munmap > 0.00 0.000000 0 1 fchmod > 0.00 0.000000 0 4 _llseek > 0.00 0.000000 0 4 rt_sigaction > 0.00 0.000000 0 3 mmap2 > 0.00 0.000000 0 2 2 lstat64 > 0.00 0.000000 0 46 geteuid32 > 0.00 0.000000 0 41 getegid32 > 0.00 0.000000 0 19 setreuid32 > 0.00 0.000000 0 19 setregid32 > 0.00 0.000000 0 5 getgroups32 > 0.00 0.000000 0 14 setgroups32 > 0.00 0.000000 0 54 getdents64 > ------ ----------- ----------- --------- --------- ---------------- > 100.00 0.285422 4354716 140047 total > > ?> ? > Case B) Remove cache lookup from samba-3.6.25,? > % time seconds usecs/call calls errors syscall > ------ ----------- ----------- --------- --------- ---------------- > 57.39 0.275347 1 510297 poll > 10.68 0.051248 1 80000 pwrite64 > 8.63 0.041410 0 840458 readv > 4.26 0.020430 0 1555919 gettimeofday > 3.53 0.016950 0 2513576 fcntl64 > 2.96 0.014199 0 165051 writev > 1.42 0.006830 0 1520391 geteuid32 > 1.38 0.006627 0 1520387 getegid32 > 0.99 0.004772 0 165850 close > 0.97 0.004667 0 421195 1 stat64 > 0.83 0.003990 0 640165 setreuid32 > 0.74 0.003569 0 165050 open > 0.70 0.003370 0 640165 setregid32 > 0.64 0.003071 0 251161 140043 getxattr > 0.63 0.003002 0 480123 setgroups32 > 0.51 0.002443 0 80019 fchmod > 0.47 0.002242 0 160039 munmap > 0.45 0.002182 0 160038 160038 lstat64 > 0.40 0.001905 0 320076 alarm > 0.38 0.001800 0 400095 getgroups32 > 0.36 0.001727 0 320076 rt_sigaction > 0.34 0.001634 0 10000 ftruncate64 > 0.33 0.001595 0 160039 mmap2 > 0.27 0.001287 0 80020 read > 0.20 0.000963 0 190058 fstat64 > 0.17 0.000814 0 160040 _llseek > 0.16 0.000786 0 25001 setxattr > 0.09 0.000423 0 15000 SYS_320 > 0.05 0.000220 4 54 getdents64 > 0.04 0.000214 0 30004 clock_gettime > 0.01 0.000038 0 800 800 connect > 0.01 0.000032 0 5000 flock > 0.00 0.000008 0 800 socket > 0.00 0.000000 0 1 restart_syscall > 0.00 0.000000 0 1 chdir > 0.00 0.000000 0 13 time > 0.00 0.000000 0 10 lseek > 0.00 0.000000 0 1 ioctl > 0.00 0.000000 0 2 umask > 0.00 0.000000 0 1 dup2 > ------ ----------- ----------- --------- --------- ---------------- > 100.00 0.479795 13586976 300882 total >? ? ? -- Regards, Jones Syue | ??? *QNAP* Systems,Inc. <http://www.qnap.com/>? ?
Dear Jones, many-many thanks for your answers, and for your times... On Wed, Apr 22, 2015 at 04:50:42PM +0800, Jones Syue wrote:> Hello Ervin, > ? > > > Do you mean that this is the "normal" way? These geteuid and > > getegid system calls are so slow? > > > > >> ?% time seconds usecs/call calls errors syscall > ?>> ? > ------ ----------- ----------- --------- --------- ---------------- > ?>> ? > 15.68 15.894980 4 4398791 getegid > >> 15.57 15.783699 4 4398801 geteuid? > > Hmm yeap > ?as earlier mentioned, > both system calls are top 2 and more than 30% during compiling. > > ?As? > 'perf top' call graph depicted, > gete{uid, gid} will go through samba stacks, glibc, > and syscalls to reach kernel finally, > this critical path spent time on stack push-pop, context switches, etc.yes, that's clear for me,> > On the previous system (Debian Wheezy, Samba 3) I've also used > > ACL's, but there were much faster than this... > > > > What should be the solution? Do you have any idea? > > > > Hmm my guess the difference is made by in-memory cache lookup[1], > samba-3 with it. > But samba-4 without it, > so non-admin users reach gete{uid, gid} heavily, > admin users could ease this pain because earlier return by > get_current_uid().ok, this is new for me - but I don't know, what can I do now...> Here is my test to imply this guess, > test-bench is uploading 5,000 files and each one is 1MB. > > Case A) samba-3.6.25 without modification, > strace show nothing through gete{uid, gid}, > and spent 85 seconds on uploading. > > Case B) Remove cache lookup from samba-3.6.25, > strace show syscalls to gete{uid, gid}, > and spent 100 seconds on uploading.this isn't a relevant different, the elapsed time increased by 25% about - but in my case, the elapsed time increased by more, that 1000%... (the compile time was about 8 seconds - take a look it as 10 secs - on Samba 3, on Samba 4 that's about 100 secs). So, the big question is what can I do now? There isn't Samba 3 package in Ubuntu, so I can't downgrade it :(. Thanks, Ervin
If you want back to samba 3.6.x sernet packages.. http://www.enterprisesamba.com/samba-packages/ubuntu/ Greetz, Louis>-----Oorspronkelijk bericht----- >Van: airween at gmail.com [mailto:samba-bounces at lists.samba.org] >Namens Ervin Heged?s >Verzonden: woensdag 22 april 2015 12:44 >Aan: Jones Syue >CC: samba at lists.samba.org >Onderwerp: Re: [Samba] Samba 4 slow write > >Dear Jones, > >many-many thanks for your answers, and for your times... > >On Wed, Apr 22, 2015 at 04:50:42PM +0800, Jones Syue wrote: >> Hello Ervin, >> ??? >> >> > Do you mean that this is the "normal" way? These geteuid and >> > getegid system calls are so slow? >> > >> >> >> ???% time seconds usecs/call calls errors syscall >> ???>> ??? >> ------ ----------- ----------- --------- --------- ---------------- >> ???>> ??? >> 15.68 15.894980 4 4398791 getegid >> >> 15.57 15.783699 4 4398801 geteuid??? >> >> Hmm yeap >> ???as earlier mentioned, >> both system calls are top 2 and more than 30% during compiling. >> >> ???As??? >> 'perf top' call graph depicted, >> gete{uid, gid} will go through samba stacks, glibc, >> and syscalls to reach kernel finally, >> this critical path spent time on stack push-pop, context >switches, etc. > >yes, that's clear for me, > >> > On the previous system (Debian Wheezy, Samba 3) I've also used >> > ACL's, but there were much faster than this... >> > >> > What should be the solution? Do you have any idea? >> > >> >> Hmm my guess the difference is made by in-memory cache lookup[1], >> samba-3 with it. >> But samba-4 without it, >> so non-admin users reach gete{uid, gid} heavily, >> admin users could ease this pain because earlier return by >> get_current_uid(). > >ok, this is new for me - but I don't know, what can I do now... > >> Here is my test to imply this guess, >> test-bench is uploading 5,000 files and each one is 1MB. >> >> Case A) samba-3.6.25 without modification, >> strace show nothing through gete{uid, gid}, >> and spent 85 seconds on uploading. >> >> Case B) Remove cache lookup from samba-3.6.25, >> strace show syscalls to gete{uid, gid}, >> and spent 100 seconds on uploading. > >this isn't a relevant different, the elapsed time increased by >25% about - but in my case, the elapsed time increased by more, >that 1000%... (the compile time was about 8 seconds - take a look >it as 10 secs - on Samba 3, on Samba 4 that's about 100 secs). > >So, the big question is what can I do now? There isn't Samba 3 >package in Ubuntu, so I can't downgrade it :(. > > >Thanks, > > >Ervin > >-- >To unsubscribe from this list go to the following URL and read the >instructions: https://lists.samba.org/mailman/options/samba >