6 ms·

Just deployed a FreeBSD droplet and I'm not sure if it's just because the host network is busier than my other droplets, but I seem to be getting about half the

by czk 12y ago

Just deployed a FreeBSD droplet and I'm not sure if it's just because the host network is busier than my other droplets, but I seem to be getting about half the network performance that I can in a default linux droplet. They are using Virtio, which is good since it doesn't require hardware emulation like the E1XXX devices on KVM. I should probably use a better test than cachefly but just wondering if theres any known tweaks/tips that should be done for FBSD on KVM with virtio devices. Disk performance is also lacking in comparison to the ubuntu droplet as shown in the pastebin. Could just be because everyone's spinning up fbsd boxes on this host? :) http://pastebin.com/raw.php?i=E8Q06XgM http://pastebin.com/raw.php?i=E8Q06XgM

sullrich 12y ago
I am also seeing really poor write speeds when comparing to my Linux droplets. 11MB/sec vs. 216MB/sec on Linux
- nine_k 12y ago
  Are these the same datacenter? The same rack? I suspect that degraded instances and overly-busy disks are not endemic to AWS.
  - czk 12y ago
    Mine are both in NYC3, so same datacenter. No clue regarding rack/host. I can't comment on AWS...
- andrewthetechie 12y ago
  With FreeBSD, in order to be able to have automatic backups work, we were required to disable journaling on the disk. This will cause the disk speed to be much slower than our Linux distributions. If you wish to have higher disk speeds, but not use backups, we recommend for you to remount your disk with journaling. https://www.freebsd.org/doc/en/articles/gjournal-desktop/configure-journal.html https://www.freebsd.org/doc/en/articles/gjournal-desktop/con...
  - vbit 12y ago
    Why did journaling interfere with automatic backups?
    - stock_toaster 12y ago
      journaling generally interferes with dump(8). It seems odd that they would be using dump to do backups though, since they are virtualizing the OS. The parent link to gjournal is weird too, since gjournal is not the same as softupdates w/journaling (SU+J). It makes me wonder if they actually disabled softupdates too. I found a random post[1] about issues (unmapped io?) running i386 freebsd with su+j in virtualbox (apparently a virtualbox bug[2]). [1]: https://forums.freebsd.org/threads/freebsd-10-i386-data-corruption-problems-in-virtual-machines-was-do-not-use-soft-update.42573/#post-239679 https://forums.freebsd.org/threads/freebsd-10-i386-data-corr... [2]: https://lists.freebsd.org/pipermail/freebsd-current/2013-November/046219.html https://lists.freebsd.org/pipermail/freebsd-current/2013-Nov...
  - alberth 12y ago
    DO disabling journaling is a big deal. What else has DO disabled and/or modified from a vanilla install?
    - shiftpgdn 12y ago
      DO modifies a lot of stuff on vanillas installs. They're one of the only providers I know of that removes the swap partition.
      - alberth 12y ago
        Where does DO document all of the modifications they make to a vanilla FreeBSD install?
  - mst 12y ago
    That deserves an explanation - you can backup non-ext2 linux partitions, surely? What have I misunderstood?
radimm 12y ago
Yes, it's really sluggish. Also both power off and resize do not work for me - as I wanted to upgrade it to compare the performance.
- andrewthetechie 12y ago
  Could you open up a support ticket so our support team could help you out? Both of those should work without issue.
atmosx 12y ago
It's not only DO. I had to create a Linux VPS in order to run a Sinatra application because when deployed on FreeBSD it took more than 60 seconds to send a response to the remote API and the connection was timed out! After performing some tests[2] I figure out that the problem was not FreeBSD per se, but the FreeBSD deployment on the specific virtual server... I think that *BSDs should be avoided because they tend to be a lot slower than linux deployments on virtual machines. [1] http://www.transip.eu http://www.transip.eu [2] https://gist.github.com/atmosx/14efea27eb2c1e38af09/ https://gist.github.com/atmosx/14efea27eb2c1e38af09/
- felixgallo 12y ago
  something must have been horribly, horribly broken on your freebsd installation or hosting environment, because there's no way any sinatra service takes 60 seconds to respond. And, your gist doesn't show a significant performance difference between linux and freebsd.
- deleted 12y ago
  [deleted]
- mst 12y ago
  > I think that *BSDs should be avoided because they tend to be a lot slower than linux deployments on virtual machines. Many virtualisation providers don't support it properly, but "should be avoided because my suppliers are stupid" is a terrible plan.
- lmm 12y ago
  FreeBSD often has better performance than Linux when both are properly hosted. I think the lesson is more like "when a provider is new to a particular system, there will be problems; for production systems use a provider that's experienced at supporting the kind of system you want to use".
- jshsmn 12y ago
  I disagree with this. FreeBSD is running fine and speedy at other providers in a virtualized platform.
smallsharptools 12y ago
FreeBSD is plenty fast. I expect Digital Ocean simply needs to work out some kinks. It will be fast soon enough.
saper 12y ago
> time dd if=/dev/zero of=/tmp/test bs=64k count=16k 16384+0 records in 16384+0 records out 1073741824 bytes transferred in 57.605991 secs (18639412 bytes/sec) 0.023u 6.128s 0:57.61 10.6% 25+172k 7+81916io 3pf+0w > sudo mount -o nosync -u / > mount /dev/gpt/rootfs on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) > time dd if=/dev/zero of=/tmp/test bs=64k count=16k 16384+0 records in 16384+0 records out 1073741824 bytes transferred in 5.135908 secs (209065631 bytes/sec) 0.016u 2.274s 0:05.16 44.1% 24+169k 8+8193io 0pf+0w
- deleted 12y ago
  [deleted]

by czk 12y ago

sullrich 12y ago

I am also seeing really poor write speeds when comparing to my Linux droplets. 11MB/sec vs. 216MB/sec on Linux

nine_k 12y ago
Are these the same datacenter? The same rack? I suspect that degraded instances and overly-busy disks are not endemic to AWS.
- czk 12y ago
  Mine are both in NYC3, so same datacenter. No clue regarding rack/host. I can't comment on AWS...
andrewthetechie 12y ago
With FreeBSD, in order to be able to have automatic backups work, we were required to disable journaling on the disk. This will cause the disk speed to be much slower than our Linux distributions. If you wish to have higher disk speeds, but not use backups, we recommend for you to remount your disk with journaling. https://www.freebsd.org/doc/en/articles/gjournal-desktop/configure-journal.html https://www.freebsd.org/doc/en/articles/gjournal-desktop/con...
- vbit 12y ago
  Why did journaling interfere with automatic backups?
  - stock_toaster 12y ago
    journaling generally interferes with dump(8). It seems odd that they would be using dump to do backups though, since they are virtualizing the OS. The parent link to gjournal is weird too, since gjournal is not the same as softupdates w/journaling (SU+J). It makes me wonder if they actually disabled softupdates too. I found a random post[1] about issues (unmapped io?) running i386 freebsd with su+j in virtualbox (apparently a virtualbox bug[2]). [1]: https://forums.freebsd.org/threads/freebsd-10-i386-data-corruption-problems-in-virtual-machines-was-do-not-use-soft-update.42573/#post-239679 https://forums.freebsd.org/threads/freebsd-10-i386-data-corr... [2]: https://lists.freebsd.org/pipermail/freebsd-current/2013-November/046219.html https://lists.freebsd.org/pipermail/freebsd-current/2013-Nov...
- alberth 12y ago
  DO disabling journaling is a big deal. What else has DO disabled and/or modified from a vanilla install?
  - shiftpgdn 12y ago
    DO modifies a lot of stuff on vanillas installs. They're one of the only providers I know of that removes the swap partition.
    - alberth 12y ago
      Where does DO document all of the modifications they make to a vanilla FreeBSD install?
- mst 12y ago
  That deserves an explanation - you can backup non-ext2 linux partitions, surely? What have I misunderstood?

radimm 12y ago

Yes, it's really sluggish. Also both power off and resize do not work for me - as I wanted to upgrade it to compare the performance.

andrewthetechie 12y ago
Could you open up a support ticket so our support team could help you out? Both of those should work without issue.

atmosx 12y ago

It's not only DO. I had to create a Linux VPS in order to run a Sinatra application because when deployed on FreeBSD it took more than 60 seconds to send a response to the remote API and the connection was timed out! After performing some tests[2] I figure out that the problem was not FreeBSD per se, but the FreeBSD deployment on the specific virtual server... I think that *BSDs should be avoided because they tend to be a lot slower than linux deployments on virtual machines. [1] http://www.transip.eu http://www.transip.eu [2] https://gist.github.com/atmosx/14efea27eb2c1e38af09/ https://gist.github.com/atmosx/14efea27eb2c1e38af09/

felixgallo 12y ago
something must have been horribly, horribly broken on your freebsd installation or hosting environment, because there's no way any sinatra service takes 60 seconds to respond. And, your gist doesn't show a significant performance difference between linux and freebsd.
deleted 12y ago
[deleted]
mst 12y ago
> I think that *BSDs should be avoided because they tend to be a lot slower than linux deployments on virtual machines. Many virtualisation providers don't support it properly, but "should be avoided because my suppliers are stupid" is a terrible plan.
lmm 12y ago
FreeBSD often has better performance than Linux when both are properly hosted. I think the lesson is more like "when a provider is new to a particular system, there will be problems; for production systems use a provider that's experienced at supporting the kind of system you want to use".
jshsmn 12y ago
I disagree with this. FreeBSD is running fine and speedy at other providers in a virtualized platform.

smallsharptools 12y ago

FreeBSD is plenty fast. I expect Digital Ocean simply needs to work out some kinks. It will be fast soon enough.

saper 12y ago

> time dd if=/dev/zero of=/tmp/test bs=64k count=16k 16384+0 records in 16384+0 records out 1073741824 bytes transferred in 57.605991 secs (18639412 bytes/sec) 0.023u 6.128s 0:57.61 10.6% 25+172k 7+81916io 3pf+0w > sudo mount -o nosync -u / > mount /dev/gpt/rootfs on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) > time dd if=/dev/zero of=/tmp/test bs=64k count=16k 16384+0 records in 16384+0 records out 1073741824 bytes transferred in 5.135908 secs (209065631 bytes/sec) 0.016u 2.274s 0:05.16 44.1% 24+169k 8+8193io 0pf+0w

deleted 12y ago
[deleted]