Tag Info

New answers tagged

0

Im not going to far out on a limb by saying this, but more than likely it is not updatedb that is causing your problems. Probably something else that you dont want, either a back-up application that you have not configured to your 'liking' or some security issue with your profile/systems group structure. Another case in which it would seem that the systems ...


0

Here's a good read on how to speed up obnam (may run up to 10 times faster): http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html Summary: add "--lru-size=1024 --upload-queue-size=512" to your commandline or config file. Note that it increases obnam's memory usage a bit.


0

iozone -Rab output.wks will do both. The command will output the flat ascii formatted results for possible import by Excel ( space and tab delimited ) as well as generating the output.wks file, which is already in BIFF (Binary Interchange File Format). The output.wks file can be opened directly with Excel, and permits one to skip importing the flat ascii ...


1

I'm very doubtful that you can get meaningful benchmarks from dd. dd just shows you how large sequential reads or large sequential asynchronous writes perform between various devices. As long as your workload consists mainly of copying large files between these filesystems you're alright. I doubt that's your workload, though. Your best bet is to profile ...


2

You need to use the write sync flags to test performance, to ensure you are actually writing on disk and not on cache. Use conv=fdatasync to force a sync of buffers after writing has ended. See here for details. time dd .... conv=fdatasync for read test, discard caches before testing: flush echo 3 | sudo tee /proc/sys/vm/drop_caches time dd ....


1

What was the command you used? dd does very different things related to percormance depending on the options. But from what you write, I think you were reading small blocks, which will get read from the disk as you ask for them, roughly. And you where writing small blocks, which will be written to the disk when the kernel feels it has time to do it - ...


0

As you get the slow down after login, technically, you need to check what can happen between login and the first shell prompt. A custom setup of the shell could do a lot of creative things that can fail in miserable ways under some special conditions - like at login before actually entering interactive mode, or while DISPLAY is not yet defined. In this ...


1

This is an 'alternative' answer to your question. I thought about comment for a while but in the end decided it might be an answer for some. Also it seems too long for a readable comment. If your objective is searching a bunch of files for a string in a faster way and are then finding grep too slow, you might be able to try git grep. Requires git to be ...


1

Two other things to keep in mind when grep-ing in large (or many) files: If you are searching for a fixed string instead of a pattern, add the -F option to grep, it will speed up your search tremendously (see Source) If you know that you are actually looking for a word, i.e. your search pattern is at bounded by non-word characters or beginning/end of the ...


3

To search a disk without opening every file: dd if=/dev/${disk_device} | grep -b 'some regex' Actually, I like this a lot better: sudo cat /dev/${some_disk} | tr -c '[:print:][:space:]' '\n\n' | grep -b 'some regex' The -b option will provide you the byte offsets for all matches. You can afterward check with the filesystem what files exist at those ...


3

First I guess this will open every file and close it before opening the second file to search for the word? is this efficient, if not is there a way more efficient? Yes, grep will open and search every file in turn. On most setups, that's the most efficient way. Unless the regexp is extremely complex, this task is firmly I/O-bound, i.e. the performance ...


5

From man grep: -H, --with-filename Print the file name for each match. This is the default when there is more than one file to search. It will print the filename first, followed by the match; which isn't what you've shown in your example results. But it is quick and easy if that doesn't cause a problem. As it's default for ...


1

Use perl: perl -nle 'print "$1 $ARGV" if /(pattern)/' a.* And for your question, yes, grep open each file to search then close it, open next file and so on. $ strace -e trace=file,close grep Power 1.txt 2.txt .... openat(AT_FDCWD, "1.txt", O_RDONLY) = 3 1.txt:Power and signal 1.txt:VDD Digital Power This pin provides power supply connection for the ...


0

As a general way to investigate a slow authentication, check /etc/pam.conf and /etc/pam.d/su (and /etc/pam.d/sshd etc.) to see what kind of authentication the login services perform. Check the system logs to see if anything is logged (look for log entries dating from the time of the authentication). In your case, it's the kernel logs that reveal the ...


1

Measured results BIOS - fast boot = 14.15 seconds BIOS + fast boot = 13.08 seconds UEFI - fast boot = 13.01 seconds [1.14 seconds faster] UEFI + fast boot = 11.30 seconds [1.78 seconds faster] UEFI stub + fast boot = 9.84 seconds2 UEFI + ultra fast boot1 = 10.87 seconds 1. no working keyboard during boot -> no access to the firmware setup utility ...


1

This is common problem on laptops. Your OS may have been configured to power saving mode. Here are instructions how to change it: Check your current CPU frequency: cat /proc/cpuinfo | grep "cpu MHz" And check it with your CPU model frequency. List your current CPU scaling governors for each core: cat ...


3

In RAID-5, unless your write was large enough to cover all data chunks for a given parity chunk, it has to read the missing data chunks in order to be able to recalculate and update parity. Thus a relatively small write on a RAID-5 can turn into a large read operation. RAID-1 does not need such additional reads, as there is no parity, it just writes to all ...


2

Monitor /sys/block/<dev>/stat for the devices you're interested in and compare the 10th parameter (io_ticks). eg, ticks = io_ticks - prev_ticks / seconds_deltatime / 10 This is the percentage of available time that the disk has spent waiting for disk io. Close to 100% would be worth checking of course, or else get really clever and compare it to the ...


5

I've not used this tunable before but you probably want to adjust the eh_timeout (error handling timeout) for the drive in question: [root@localhost device]# cat /sys/block/sda/device/eh_timeout 10 [root@localhost device]# The above shows sda set to 10 seconds. From Red Hat Knowledgebase: In certain storage configurations (for example, configurations ...


3

You should probably just use fmt or fold or pr or one of those. Here's fmt: until [ $((i=i+1)) -gt 10000 ] do printf %s\ words and more words done | fmt OUTPUT words and more words words and more words words and more words words and more words words and more words words and more words words and more words words and more words words and more words words ...


2

grep definitely works line based, as does sed. It won't necessarily speed up searching, but producing the output for a matching line should be quicker.


8

SHELL SEQ: Probably a useful means of bench-marking a shell's performance is to do a lot of very small, simple evaluations repetitively. It is important, I think, not just to loop, but to loop over input, because a shell needs to read <&0. I thought this would complement the tests @Gnouc already posted because it demonstrates a single shell ...


0

Following the question strict: mycurl() { START=$(date +%s) curl -s "http://some_url_here/"$1 > $1.txt END=$(date +%s) DIFF=$(( $END - $START )) echo "It took $DIFF seconds" } export -f mycurl seq 100000 | parallel -j0 mycurl Shorter if you do not need the boilerplate text around the timings: seq 100000 | parallel -j0 --joblog ...


4

Let do a benchmark. With bash: $ strace -cf bash -c 'for i in $(seq 1 1000); do bash -c ":"; done' % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 99.12 0.376044 188 2004 1002 wait4 0.74 0.002805 3 1002 clone 0.03 ...


2

As someone who is using a btrfs filesystem with Arch Linux for almost 2 years now I can safely say that there does not seem to be a practical limit on the number of snapshots that can be easily reached. There are some caveats though. btrfs filesystem can lead to fragmentation. It is therefore advisable to use the online defragmentation feature built into ...


0

There is a user guide from every HDD manufacturer, and I have read a such one. This is not good idea to defragment SSD. There is not a mechanical parts in SSD like in HDD-s and organization of DATA is other type. The seeking of data in SSD is different and no need to be defragmented. The live of SSD will be shorter, if- defragmenting frequently. At ...


4

What is difference between | and <<()? There is a difference between them: | cause each command run in a separated subshell. <() run the command, which is substituted in background. For the next two question, we will do some strace: pipe: $ strace -fc bash -c 'tac /usr/share/dict/american-english | grep qwerty' $ time seconds ...


10

The construction <(tac file) causes to shell to: Create a pipe with a name On systems such as Linux and SysV which have /dev/fd, a regular pipe is used, and /dev/fd/<the-file-descriptor-of-the-pipe> is used as the name. On other systems, a named pipe is used, which requires creating an actual file entry on disk. Launch the command tac file and ...



Top 50 recent answers are included