quick and dirty code /snippets / making the life hopefully easier
rsync via ssh
rsync -arlpt /source user@host:/target
have fun
all of the it stuff we want to share here
quick and dirty code /snippets / making the life hopefully easier
rsync via ssh
rsync -arlpt /source user@host:/target
have fun
quick and dirty code /snippets / making the life hopefully easier
Filesystem used (freeBSD)
all 3 of them will do the Trick
mount
mount|cut -f4 -d ' '|tr -d '(,'| sort| uniq -c| sort -rn
gpart show
have fun
HDD speed test the quick and dirty way (with dd and hdparm)
(be aware only do what you understand, we don’t care if something goes sideways, and don’t blame us it’s your own risk)
Monitoring read and write speeds of storage devices is a good way to determine genuine products and determine disk health overtime. Important: When writing to a device (such as /dev/sda), the data stored there will be lost.
For that reason, you should only use empty RAID arrays, hard disks or partitions. ‘Nuff said !
Server Throughput-1 (Streaming I/O)
# dd if=/dev/zero of=/d3/tempfile bs=1G count=1 oflag=dsync
output something like this:
me-1: 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 10,116 s, 106 MB/s
me-2: 1073741824 bytes (1.1 GB, 1,0 GiB) copied, 5,112 s, 210 MB/s
me-3: 1073741824 Bytes (1,1 GB, 1,0 GiB) copied, 2,7323 s, 393 MB/s
Server Throughput-2 (Streaming I/O)
# dd if=/dev/zero of=/d3/tempfile bs=1G count=1 oflag=direct
output something like this:
me-1: 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 8,5628 s, 125 MB/s
me-2: 1073741824 bytes (1.1 GB, 1,0 GiB) copied, 32,474 s, 33.1 MB/s
me-2: 1073741824 Bytes (1,1 GB, 1,0 GiB) copied, 2,73749s, 392 MB/s
Read Speed
# dd if=tempfile of=/dev/null bs=1M count=1024
output something like this:
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 3,70806 s, 290 MB/s
Read Speed w Buffer
# dd if=tempfile of=/dev/null bs=1M count=1024
output something like this: (this wone should run multiple times)
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,324511 s, 3,3 GB/s
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,300225 s, 3,6 GB/s
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,303069 s, 3,5 GB/s
1073741824 Bytes (1,1 GB, 1,0 GiB) copied, 0,135352 s, 7,9 GB/s
1073741824 Bytes (1,1 GB, 1,0 GiB) copied, 0,131451 s, 8,2 GB/s
1073741824 Bytes (1,1 GB, 1,0 GiB) copied, 0,133496 s, 8,0 GB/s
Read Speed w Cache
#hdparm -tv /dev/sda1
428 MB in 3.00 seconds = 142.61 MB/sec
512 MB in 1.16 seconds = 441.88 MB/sec
Read Speed n Cache
#hdparm -tT –direct /dev/sda1
Timing O_DIRECT cached reads: 494 MB in 2.00 seconds = 246.86 MB/sec
Timing O_DIRECT disk reads: 408 MB in 3.00 seconds = 135.99 MB/sec
Timing O_DIRECT cached reads: 664 MB in 2.00 seconds = 331.58 MB/sec
Timing O_DIRECT disk reads: 512 MB in 1.23 seconds = 417.88 MB/sec
These are some of the methods that can be used to benchmark hard disks and determine their read and write speeds.
For what, yeah it depends … I use it to see if our builds perform, or how long will it take to get the backup done 😉
XML-RPC was a solid solution for some of us, till the day when problems occurred due to remote publishing
to a WordPress site. However, with wp_xmlrpc, just because the XML-RPC specification was developed
before WordPress was even created, came some security holes that ended up being pretty nasty
for some WordPress site owners.
One Way or another, there are always ways trying to avoid getting on this trail,
use plugins, or some code, which means you are going to disable that features (wp_xmlrpc) entirely.
When you’re on that golden road, that you need some features, you should use the work around plugIns
available for these features.
Getting more sleep and less headaches, the way we handle it here, is adding some code to .htaccess.
(be aware and knwo what you are doing, we don’t care, and we are not to blame if somehing goes wrong)
# ---- Block WordPress xmlrpc.php requests ----
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
# ---------------------------------------------
This will disable wp_xmlrpc, and answer requests with 403.