This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Astaro on 16GB CF-Card (Flash) not usable

After successful installation of ASG 7.1 on a 16GB CF-Card with IDE-adapter, the system works, but is too slow to be used. The web-interface response times are around minutes. A detailed analysis shows, that the io queue is full all the time.

The CF-Card used is a 16GB Sandisk Extreme III which achieves datarates measured by hdparm around 15 MByte/s with MDMA2. The same measuring during the running ASG shows only 2 MByte/s although ASG is fresh installed and no networks attached.

I assume, that the cache on CF-Cards is way too small with 1 kByte to be used by the Linux filesystems in combination with the requirements the Astaro processes has on the filesystem.

The background of using a CF-Card was to build an Astaro gateway with 10 ethernet ports into a 2 units high 19" case. There wasn't any room for a hardware RAID controller like a 3ware besides the two 4 quad-port gigabit cards, so some other reliable storage device was needed.

Of course, Astaro is not to blame, as officially CF-Cards are not supported. This note was only written for other readers who might have the same idea about using CF-Cards.


This thread was automatically locked due to age.
Parents
  • FYI,
    CF cards have much slower write speeds than read.
    CF cards will quickly wear out with a lot of writes.

    Barry
  • Yep, you really need something designed to be a SSD if you want something that doesn't have moving parts.
  • I understand your concern about sector wear which had been valid until only a few months ago. But with current of-the-shelf CF-Cards from large brands the failure rate for repeated write on the same sector isn't an issue any more. You can even buy "industry quality" CF-Cards for about the double prize than normal ones with life-long garanty for use as SSD. There is still an issue with slow writes as Barry mentioned with seems to be caused by the tiny cache and the flash technology itself.

    I guess with some tweaks around the logging and filesystem, Astaro could be used well on a CF-Card for some use cases without proxy caches.
  • You could try with setting the "sync(0);" option line in /etc/syslog-ng.conf to another value, maybe 100? Not recommended for regular use because this might have some side-effects with the logging and reporting backend, but would surely help out in your situation. Also recommended would be a good-sized ramdisk replacing /tmp and maybe some caching directories, reducing writes to the harddisk.

    Cheers,
     andreas
  • You could try with setting the "sync(0);" option line in /etc/syslog-ng.conf to another value, maybe 100?


    I tried, sync(1000) and also enabled remote syslog with no local logging on the web interface. The ext3 mount options were changed from "ordered data" to "writeback".

    However, still not usable as io wait is around 50 - 90% and CPU load around 3 with no network interfaces in use.

    So we will go back to the harddisk installation now.
Reply
  • You could try with setting the "sync(0);" option line in /etc/syslog-ng.conf to another value, maybe 100?


    I tried, sync(1000) and also enabled remote syslog with no local logging on the web interface. The ext3 mount options were changed from "ordered data" to "writeback".

    However, still not usable as io wait is around 50 - 90% and CPU load around 3 with no network interfaces in use.

    So we will go back to the harddisk installation now.
Children
  • Change CF to SolidStateDisk or real HardDisk[:)]

    Gregor Kemter
  • What does the output of vmstat 1 show while the IO wait is high?

    Can you verify that Astaro is using DMA to access the drive? Some IDE-CF adapters are very poor.
  • What does the output of vmstat 1 show while the IO wait is high?

    Can you verify that Astaro is using DMA to access the drive? Some IDE-CF adapters are very poor.



    The "bytes out"  column showed around 1 MByte/s.
    A "hdparm -t /dev/sda" showed around 4 MByte/s on the system partition while a "hdparm -t /dev/sdb" on an unused CF-card on the same machine showed around 13 MByte/s.

    MDMA2 was used according to hdparm,  not UDMA.
  • Change CF to SolidStateDisk or real HardDisk[:)]

    Gregor Kemter


    As I now read, those SSD aren't that much more expensive than CF any more.

    Any experience with those SATA SSDs?

    http://www.transcend.de/products/ModDetail.asp?ModNo=177

    Performance with UDMA in KByte/s:
    Read: 30467
    Write: 28611
    Random Read: 29383
    Random Write: 7497
  • The "bytes out"  column showed around 1 MByte/s.
    A "hdparm -t /dev/sda" showed around 4 MByte/s on the system partition while a "hdparm -t /dev/sdb" on an unused CF-card on the same machine showed around 13 MByte/s.

    Yeah, only being able to write 1 MB/s doesn't seem like it's going to cut it. There is probably some tuning that could be done to try to batch writes to the CF in larger chunks, but even then, if it's only capable of 4 MB/s peak (and hdparm reports read speeds, not write speeds which would be slower), that's just very slow.
    As I now read, those SSD aren't that much more expensive than CF any more.

    Any experience with those SATA SSDs?

    Well, It seems that SSDs are still a 2-3x more expensive than your basic CF card, but looking at the specs, they should perform a lot better than your typical CF card.

    Reading some reviews of the Transcend SSD drives, it seems that while they seem to be the least expensive on the market, the performance isn't that good.