search for: cprocess

Under certain circumstances, my compiler outputs basic blocks having the same function: bb_97: ; preds = %bb_1 %476 = getelementptr inbounds %LMtop.I0.ARType, %LMtop.I0.ARType* %0, i64 0, i32 6 %477 = bitcast i8** %476 to %LBstd.Cprocess.CRType** %478 = load %LBstd.Cprocess.CRType*, %LBstd.Cprocess.CRType** %477, align 8 %479 = getelementptr inbounds %LBstd.Cprocess.CRType, %LBstd.Cprocess.CRType* %478, i64 0, i32 3 %480 = bitcast i8** %479 to %LMtop.I0.ARType** store %LMtop.I0.ARType* %0, %LMtop.I0.ARType** %480, align 8...

...rcumstances, my compiler outputs basic blocks having the same function: > > > > bb_97: ; preds = %bb_1 > > %476 = getelementptr inbounds %LMtop.I0.ARType, %LMtop.I0.ARType* %0, i64 0, i32 6 > > %477 = bitcast i8** %476 to %LBstd.Cprocess.CRType** > > %478 = load %LBstd.Cprocess.CRType*, %LBstd.Cprocess.CRType** %477, align 8 > > %479 = getelementptr inbounds %LBstd.Cprocess.CRType, %LBstd.Cprocess.CRType* %478, i64 0, i32 3 > > %480 = bitcast i8** %479 to %LMtop.I0.ARType** > > store %LMtop.I0.ARType...

..._____IP:/DEST_PATH/ abc 3798 3797 0 01:12 ? 00:00:13 ssh DEST_____IP rsync --server -urze.iLs --compress-level=9 --bwlimit=512 --delay-updates . /DEST_PATH/ vangelis 8431 8371 0 18:04 pts/7 00:00:00 grep --color=auto rsync $ sudo strace -p 3794 Process 3794 attached wait4(-1, ^CProcess 3794 detached <detached ...> $ sudo strace -p 3795 Process 3795 attached wait4(3796, ^CProcess 3795 detached <detached ...> $ sudo strace -yy -p 3796 Process 3796 attached wait4(-1, ^CProcess 3796 detached <detached ...> $ sudo strace -yy -p 3797 Process 3797 attached select...

...(7, [], [6], [], {60, 0}) = 0 (Timeout) 17:38:34 select(7, [], [6], [], {60, 0}) = 0 (Timeout) 17:39:34 select(7, [], [6], [], {60, 0}) = 0 (Timeout) 17:40:34 select(7, [], [6], [], {60, 0}) = 0 (Timeout) 17:41:34 select(7, [], [6], [], {60, 0}) = 0 (Timeout) 17:42:34 select(7, [], [6], [], {60, 0}^CProcess 13478 detached <detached ...> root at pc5: ~ $ root at pc5: ~ $ strace -f -t -s 1024 -p 13479 Process 13479 attached 17:37:36 select(2, [], [1], [], {55, 15138}) = 0 (Timeout) 17:38:31 select(2, [], [1], [], {60, 0}) = 0 (Timeout) 17:39:31 select(2, [], [1], [], {60, 0}) = 0 (Timeout) 17:40...

...00, by ='day') a lot while digging into it, i strace'd the running process and it seems the bulk of the time is spent checking for /etc/localtime stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 strace -cp 2964 Process 2964 attached - interrupt to quit ^CProcess 2964 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 94.61 0.006387 0 55872 stat 2.58 0.000174 0 568 read 1.42 0.000096 0 285...

...x)\320\0314\223\323\3335Y\312\313\307"..., 32776) = 32776 select(6, [5], [4], [5], {60, 0}) = 1 (out [4], left {59, 999998}) write(4, "\4\200\0\7\316\214\260\341:\263P\214\373n\313\10\333 }\323\364Q\353\r\232d\204\257\\Q\306/"..., 32776) = 32776 select(6, [5], [4], [5], {60, 0}^CProcess 16776 detached <detached ...> citadel:/home/archon810 # strace -p 16777 Process 16777 attached select(4, [3], [], [3], {38, 210908}^CProcess 16777 detached <detached ...> citadel:/home/archon810 # strace -p 16776 Process 16776 attached select(6, [5], [4], [5], {48, 295874}^CProcess 16...

...ot, we noticed that on a busy server, imap-login can sometimes take 100% CPU and remain there indefinitely. We grabbed a gdb trace while it was happening: dovenull 36053 31.2 0.0 60460 17316 ? R 04:38 11:55 dovecot/imap-login root at server [~]# strace -p 36053 Process 36053 attached ^CProcess 36053 detached root at server [~]# gdb atGNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. Ther...

......, 4096) = 4096 read(4, "INTERNAL\t\tIBM9448\t\t1\nmodule\tINTE"..., 4096) = 3036 read(4, "", 4096) = 0 close(4) = 0 munmap(0x7f4310e06000, 4096) = 0 write(3, "@RSYNCD: 31.0\n", 14) = 14 read(3, ^CProcess 30534 detached <detached ...> rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(632) [Receiver=3.1.0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20131108/230fbe1b/attachment.html&...

Hi again, I'd like to expand on the performance issues and plead for help. Here's one case which shows these odd hiccups: https://i.imgur.com/CXBPjTK.gifv. In this GIF where I switch back and forth between copy operations on 2 servers, I'm copying a 10GB dir full of .apk and image files. On server "hive" I'm copying straight from the main disk to an attached volume

Hi, I'm trying to squeeze performance out of gluster on 4 80GB RAM 20-CPU machines where Gluster runs on attached block storage (Linode) in (4 replicate bricks), and so far everything I tried results in sub-optimal performance. There are many files - mostly images, several million - and many operations take minutes, copying multiple files (even if they're small) suddenly freezes up for

...busy server, imap-login can sometimes take 100% CPU and remain there indefinitely. We grabbed a gdb trace while it was happening: > > dovenull 36053 31.2 0.0 60460 17316 ? R 04:38 11:55 dovecot/imap-login > root at server [~]# strace -p 36053 > Process 36053 attached > ^CProcess 36053 detached > root at server [~]# gdb > atGNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6) > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change...

...server --sender -vlHogDtpAXrze.iLsf --numeric-ids . / root 8755 0.0 0.0 7836 872 pts/1 S+ 21:02 0:00 grep rsync root at st1:~# strace -p 4942 Process 4942 attached - interrupt to quit ^CProcess 4942 detached root at st1:~# strace -p 4942 Process 4942 attached - interrupt to quit ^CProcess 4942 detached root at st1:~# gdb /usr/bin/rsync 4942 --snip-- 0x00007f7a75e48914 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007f7a75e48914 in ?? () from /lib/x86_64-linux-gnu/libc.so....

Now that we can gather diagnostic info, I think I know why our P2Vs kept failing last week. Another one just died right in front of my eyes. I think either the Ethernet or NFS server at this site occasionally "blips" offline when it gets busy and that messes up P2V migrations. The RHEV export domain is an NFS share offered by an old Storagetek NAS, connected over a 10/100 Ethernet.