New answers tagged

0

It's theoretically possible that the simultaneous (concurrent/parallel) execution might be slower.  It's conceivable that the operating system might keep each directory clustered.  I.e., the contents of dir1 might have inode numbers that are close to each other, and use data blocks that are close to each other.  And the same might be true for dir2.  But the ...


1

Like alx741 said I don't think you're going to get any real benefit one way or the other unless they're on separate file systems. I did some testing with a 700MB file. Here are my tests that backup my thoughts. I don't have multiple local partitions to play with so I can't test that. Here it is as one command sequentially. time rm -f test.dat1 test.dat2 ...


3

It depends. If the files being removed are in the same file system and hardware device they will eventually be sequential anyways, because the operating system will wait the physical resource to do the actual operations in the hardware. Although each instance of rm will queue the operations so one is available when the other finishes, don't expect a big ...


1

fs_usage shows information about file system usage (and related things). Given that, I suspect THROTTLED from fs_usage indicates it is disk access being throttled and not CPU (although THROTTLED is not clearly documented in the man page). OSX reduces I/O throughput of idle applications to give better performance to active ones (see this Ars article) so it's ...


0

sorry can't comment Check if it gets better if you turn hardware acceleration on. Download the video, open with Chrome (which seems to be your browser). If it uses less CPU, it's a problem with how your browser plays HTML5 video and you can fix it by opening the video in new tab (which sadly will be problematic with Youtube and the similar). If it uses the ...


0

What you want is kind of the opposite of virtualisation, a cluster. I'll try to explain the difference as simply as possible. Virtualisation is having multiple virtual machines running on one (or more) physical machines. This allows you to make more efficient use of your existing hardware, by running multiple completely separate virtual machines on the ...


2

Look into batch queueing software like TORQUE, PBS, Slurm etc. It lets you create a queue where users submit their tasks, and the software runs that on the machines available. Please note that this approach works well only with non-interactive stuff.


0

I would start by measuring the speed of the dumbest TCP stream possible. A plain FTP (not SFTP or FTPS) would do it. If for some reason FTP doesn't work (firewalls can be an issue), try netcat. FTP just literally throws bytes at a socket. As long as it's using the full TCP packet size, and we're talking about a single file, you can't use TCP more ...


0

SCP is very simple tool to simple copy files back and forth. It was not designed to super-fast speeds and it has really small buffers on both sides. If you aim for performance, you should use sftp or rsync. About the speed measures, lets draw some diagram: [host A] --- ??? mbit --- [host B] \ / \ 300 mbit ...


0

Assuming perf works on your system (it just falls over on my old laptop), you can get more fine-grained CPU accounting, which shows % of the total, i.e. ignores all your idle time so you'll get nice big percentages: perf top --sort=comm I guess it doesn't really help as if it's more IO-related, though it will at least highlight the top tasks which are ...


1

Those threads serve different purposes. There is a main thread that starts and waits until shutdown, there are several background threads in Innodb and Aria, and so on. Attach gdb and do thread apply all bt to see what they are doing - most likely they are sitting there doing nothing waiting for for some event to happen.


3

X forwarding is often slow, even on a relatively fast network. It suffers from both bandwidth and latency: many applications often wait for an answer from the server, and that can translate into noticeable delays. You can improve the bandwidth by compressing. SSH can do compression with the -C option. You can also use dxpc, which is a special-purpose ...


1

You are mixing up terms. The first thing is X11 forwarding and it is inefficient by definition and you can't do almost anything about that (it is not made for high-latency connections and decades ago]. In comparison to the other method, it is inefficient, because it is transferring whole gui (of broswer?) over the newtwork. The other is SOCKS proxy (...



Top 50 recent answers are included