Exceed on Demand only sends the right Alt key to the viewed X desktop (Linux machine you’re logging into). I use this AutoHotkey script to send both Alt keys to Linux:
From a previous post, I noticed the SSD that I’m using in my server showed only a 50 MB/s write speed. That’s weird because the specs show around 145 MB/s.
So, I decided to investigate some more. I removed the SSD from the zpool and did some dd tests on it.
server# dd if=/dev/zero of=/dev/ada3 bs=4M count=32
32+0 records in
32+0 records out
134217728 bytes transferred in 1.587130 secs (84566307 bytes/sec)
server# dd if=/dev/zero of=/dev/ada3 bs=4M count=128
128+0 records in
128+0 records out
536870912 bytes transferred in 5.888121 secs (91178650 bytes/sec)
server# dd if=/dev/zero of=/dev/ada3 bs=4M count=1024
1024+0 records in
1024+0 records out
4294967296 bytes transferred in 45.720133 secs (93940394 bytes/sec)
server# dd if=/dev/zero of=/dev/ada3 bs=4M count=16384
^C6528+0 records in
6527+0 records out
27376222208 bytes transferred in 277.460367 secs (98667145 bytes/sec)
That last run (which I interrupted) showed 94 MB/s.
The disks I am using (in a mirror) as a ZIL are much smaller. Let’s check their write performance:
errors: No known data errors
server# zpool remove tank mirror-1
server# dd if=/dev/zero of=/dev/gpt/zil0 bs=4M count=1024
1024+0 records in
1024+0 records out
4294967296 bytes transferred in 88.818498 secs (48356676 bytes/sec)
They are around 46 MB/s write speed. Hmm. If I were willing to give up the mirror on the ZIL, I could break up the 64 GB SSD into a two-part partition and use one part as a ZIL and the rest as the L2ARC cache.
I’d also free up a couple of SATA ports in the process–which is probably good, because I’m using a 4X SATA PCI card that’s probably very limited on bandwidth anyway. Rather than pushing this platform to its extreme, it might make sense to live with less.
Note that the Samba shares resides in a ZFS pool with dedup turned on. Since the blocks that make up the file being sent are probably already on the pool, it’s not necessarily writing the block data to disk. Using the same method as last time:
That’s better, but still not as good as before. One thing to note: I did not delete the file after the first run copied it over to the server. This shouldn’t matter much, since it’s in a snapshot of the zfs dataset somewhere, so the dedup algorithm should always return that the file doesn’t need to be saved to disk–although the algorithm itself probably takes quite a while to run on the server’s Atom D525 processor. Anyway, I deleted the file this time
Note that the second run here is 16 seconds faster than the first. Seems like caching effects have a 16 second impact. The dedup on/off has a 9 second impact.
Check-summing on dedup makes a difference. I notice during the send transfer that with dedup on, kernel takes 100% of a CPU (of 4 hyperthreads), whereas with it off, kernel only takes 3%. Since we have a multi-threaded CPU, Samba takes one thread and dedup (kernel) takes another. It doesn’t really impact things much (much being greater than 10%)–which is an assumption the ZFS designers made with dedup. The assumption being that CPU processing is more available than I/O bandwidth.
In my case, on my Atom D525 they may be about even. Note that the first time I ran the send, the time was 199 seconds. One hypotehsis is that in this case, the checksum had to run but the file still needed to be stored to disk–however, I’m almost certain that a snapshot of the data exists in the pool (I snapshot every 15 minutes). Another possibility is that there are some dedup data structures that zfs needs to create on the first write, and so the data structures were being created in addition to the checksums being run. I’m basically speculating here.
Either build Java without IPv6, or you need the following in /etc/rc.conf:
tomcat60_enable=”YES”
tomcat60_java_opts=”-Djava.awt.headless=true -Djava.net.preferIPv4Stack=true”
(The java.awt.headless is if you’re running without an X console.)
Also, delete everyting in /usr/local/apache-tomcat-6.0/webapps/ except for subsonic and subsonic.war and rename these ROOT and ROOT.war respectively. Make sure www:www is the owner of everything (including your subsonic databases in /var/subsonic).
While you’re here, edit webapps/ROOT/WEB-INF/classes/ehcache.xml and change to (just an example):
Looks basically like that other Corsair I bought a month ago. I basically bought another one so I can set up my FreeBSD root as a mirror of two 16 GB USB drives that are relatively fast for USB (even in a USB 2.0 port). This is in a USB 3.0 port:
I’m about to upgrade to FreeBSD. While I csup the latest RELENG-9.0 branch, I’m looking at my Samba performance on 8.2.
I’m measuring a copy of FreeBSD-8.2-RELEASE-i386-dvd1.iso to the Samba server using the following batch file (taken from here):
@echo off
set starttime=%TIME%
set startcsec=%STARTTIME:~9,2%
set startsecs=%STARTTIME:~6,2%
set startmins=%STARTTIME:~3,2%
set starthour=%STARTTIME:~0,2%
set /a starttime=(%starthour%*60*60*100)+(%startmins%*60*100)+(%startsecs%*100)+
(%startcsec%)
set endtime=%time%
set endcsec=%endTIME:~9,2%
set endsecs=%endTIME:~6,2%
set endmins=%endTIME:~3,2%
set endhour=%endTIME:~0,2%
if %endhour% LSS %starthour% set /a endhour+=24
set /a endtime=(%endhour%*60*60*100)+(%endmins%*60*100)+(%endsecs%*100)+(%endcsec%)
set /a timetaken= ( %endtime% – %starttime% )
set /a timetakens= %timetaken% / 100
set timetaken=%timetakens%.%timetaken:~-2%
That’s a 1751164811 byte file, so that’s 21.59 MiB/s. To receive:
@echo off
set starttime=%TIME%
set startcsec=%STARTTIME:~9,2%
set startsecs=%STARTTIME:~6,2%
set startmins=%STARTTIME:~3,2%
set starthour=%STARTTIME:~0,2%
set /a starttime=(%starthour%*60*60*100)+(%startmins%*60*100)+(%startsecs%*100)+
(%startcsec%)
:TimeThis
copy \\SERVER\Downloads\FreeBSD-9.0-RELEASE-amd64-dvd1\FreeBSD-9.0-RELEASE-amd64-dvd1.iso C:\Users\Poojan\Desktop
set endtime=%time%
set endcsec=%endTIME:~9,2%
set endsecs=%endTIME:~6,2%
set endmins=%endTIME:~3,2%
set endhour=%endTIME:~0,2%
if %endhour% LSS %starthour% set /a endhour+=24
set /a endtime=(%endhour%*60*60*100)+(%endmins%*60*100)+(%endsecs%*100)+(%endcsec%)
set /a timetaken= ( %endtime% – %starttime% )
set /a timetakens= %timetaken% / 100
set timetaken=%timetakens%.%timetaken:~-2%
So, these are a bit more consistent: 22.76 MiB/s and 23.24 MiB/s. Running it a third time gives 16.4 MiB, but I was running gstat, top, etc. while that was going.
With epair, there are two interfaces created epair0a and eapir0b that are direct connections between each other (like an Ethernet cable). When used with jails using an ifconfigvnet command, one side (epair0b for example) sgoes inside the jail. Since the other side of this virtual direct-connection stays on the outside of the jail, the epair pairs act as an Ethernet tunnel inside/outside the jail. You can use firewall rules either outside the jail or inside the jail to control traffic.
