Disappointing performance

I have a Lenovo M700. Despite its very small size, it's a powerful system -- fast Intel processor, 8GB RAM and a 128GB SSD. I was running Arch Linux on this system and experienced one of the risks of a rolling release system -- the Linux kernel guys broke the network driver for this system (E1000). I used this as an excuse to install FreeBSD 11.1, after backing up the Linux install. The FreeBSD install I did was ZFS, legacy GPT.

I have a suite of financial management software that I wrote for myself. My financial data is stored in a Sqlite database. One of the suite's components is a report generator that is written in C (I also have Rust version -- I am gradually porting some of the components to Rust). The report generator is compute-intensive and I believe most of the time is spent in Sqlite, not in my code. There are two parts to this that can be run in parallel and those are run in separate threads.

With Arch running on this hardware, the elapsed runtime for the report generator is about 40 seconds for both the C and Rust versions. The runtime on FreeBSD is about 3x longer, a bit over 120 seconds. In the Rust case, the compiler versions were identical. The gcc compiler on FreeBSD is older than on Arch (gcc5 vs. gcc7) but I don't believe that Rust uses gcc as a back-end. If I'm right, that would eliminate the gcc version difference as the culprit, given that I saw same timings with Rust. The sqlite versions are the same (1.21). I'm guessing this is an ext4 vs. zfs issue. The report generator only reads the database.

I also had difficulty with X on this machine (it has Intel graphics hardware and yes, I installed xf86-video-intel). Instead of using the Intel driver, it used the Vesa driver and the graphics performance was awful. I tried X -configure to generate a usable xorg.conf to try to force the use of the Intel driver, but that failed.

I ended up restoring Arch because of these problems. But if someone has a bright idea about the performance issue, I have another machine with which i might be able to do some useful experimenting.
 
Is there a reason you are using ZFS? Are you using it for a feature? I don't see a practical use for ZFS on a laptop except for jails or GELI. UFS would be better IMHO.
 
The Lenovo M700 has a Skylake processor. Graphic acceleration through the i915kms driver is not yet supported but in the works.
That'll explain the awfull performance in Xorg, though that shouldn't affect the processing power of your cpu.
 
Is there a reason you are using ZFS? Are you using it for a feature? I don't see a practical use for ZFS on a laptop except for jails or GELI. UFS would be better IMHO.

This machine is not a laptop; it's a small desktop system. I chose ZFS because of its data integrity features.
 
The Lenovo M700 has a Skylake processor. Graphic acceleration through the i915kms driver is not yet supported but in the works.
That'll explain the awfull performance in Xorg, though that shouldn't affect the processing power of your cpu.

Thanks -- one aspect of this explained.
 
While I wouldn't run CURRENT on a production system, some of the later video cards are supported at the moment, using the drm-next-kmod package (or port--package seems to not be working well for me at least.)

http://srobb.net/freebsdintel.html

Thanks for the info, but my motivation for installing FreeBSD was greater stability, given that Arch and the Linux kernel people had caused some instability. But I have a workaround for that problem (the breakage seems to prevent the network from coming up during booting, but it can be brought up manually after the system is up), So, as you yourself suggested, I don't think it makes sense to take on the possible problems CURRENT might present. Especially without the prospect of better performance of my application.
 
While I wouldn't run CURRENT on a production system, some of the later video cards are supported at the moment, using the drm-next-kmod package (or port--package seems to not be working well for me at least.)

http://srobb.net/freebsdintel.html
It is a moving target with debug flags enabled all over the place. debug flags are prescription for sluggish performance. The OP should be well advises to stick to his Arch Linux. ZFS is mighty file system but his anemic desktop processor and tiny 8 GB of non-ECC RAM are prescription for disappointment.
 
When I do run CURRENT (and I mention this on the page) one of the first steps is to run make kernel KERNCONF=GENERIC-NODEBUG which helps with that. But, that being said, no argument from me, if it's production, run Arch or another flavor of Linux. (Lately, I've been playing with and liking VoidLinux, but as it's a relatively niche distribution, packages and documentation can be lacking).
 
When I do run CURRENT (and I mention this on the page) one of the first steps is to run make kernel KERNCONF=GENERIC-NODEBUG which helps with that. But, that being said, no argument from me, if it's production, run Arch or another flavor of Linux. (Lately, I've been playing with and liking VoidLinux, but as it's a relatively niche distribution, packages and documentation can be lacking).

"Production" is not quite the word. I'm a retired software manager and developer and the systems I'm talking about are personal machines. An alternative to Arch on that machine is Dragonfly, with which I've been quite impressed (I run it on another of my machines). I tried FreeBSD because I wanted to see where things stood, but it's clearly not suitable for that particular piece of hardware.

I had a look at Void quite a while ago, probably more than a year, and at that point it was clearly not ready for prime time. Perhaps it has improved. Alpine is another interesting Linux distribution, but also lacked the level of finish of a system like Arch (documentation isn't good) and their use of the musl libc and busybox is sometimes a problem. But when it works, it's fast! Debian is another possibility, for good stability, and can be installed without a desktop, which I prefer (I just use a window manager and few accessories).
 
I don't see a practical use for ZFS on a laptop except for jails or GELI.
No? Instant snapshots, boot environments, compression, zfs send/receive, zvols, ...

Could give a try to 10.4 + graphics/drm-next-kmod. <-- this port does not work with 11.x.
It doesn't work on 10.4 either. Just look at the OSVERSION check in the port's Makefile.

I'm guessing this is an ext4 vs. zfs issue. The report generator only reads the database.
Does it perform better if you put the database on a tmps(5)? Or is it still as slow as before?
 
My guess for the bad ZFS performance is I/O amplification due to the blocksize of the pool.

Did you set the vfs.zfs.min_auto_ashift value to 12 (or with SSDs even higher) before creating the pool?
Other important factors are atime (off!) and compression (LZ4) on the dataset where your DB resides, especially if it doesn't fit into ram. Atime will completely destroy performance for lots of small reads to a file, as every read would also induce a write to correct the metadata.

Yes, ext4 will still be faster, but you don't have any resiliency and error detection/correction. If throughput of the single drive really is the limiting factor here, throw another SSD into the pool and create a mirror - read IOPS and bandwidth will be doubled.
 
sko I don't have SSDs (I have a SSHD (the first Seagates with 32 GB NAND) and a 7,200 RPM), but I'm still worried my I/O isn't all it could be... I didn't bother setting blocksize because 1. I figured the software would know what's best; and 2. I'm not sure if my drives have writable 512 bytes blocks...

How do I figure it out? What's the right settings? Also, do you know anything about SSHDs? Nobody seems to know anything about them, I thought they were an awesome idea, but seem to be rather unpopular... I'm not even sure if it works with an encrypted drive... To be honest, I never had to worry about such things before, never got this far before...
 
Back
Top