The same goes for the other Orange Pi PC I have, where I write weather data in 5 minute intervals for several years. No issue either.
I have a very good power distribution (custom made cables, high quality 40A/5V power supply), which makes a big difference in reliability, overall.
My Raspberry Pi has uSD card issues every 3rd boot (probably gets into a read-only mode). I have to boot it multiple times to get the uSD card to work. It uses Rpi branded power adapter.
Also, for years (~7) I used a single 16G SD card for all my camcoder recordings. It has to had handled >1TB and it still works.
I really can't complain about any of my (u)SD cards. (I run a cluster of 11 boards and I had one uSD card failure over 3 years. And it was some cheap "Samsung" from aliexpress. Verified Sandisk A1 cards never failed me so far.)
RPi3+ also support booting from USB and Ethernet so you really don't need an SD card in a lot of cases either.
Can you give examples of microSD cards like this? What googling for "high endurance" turns up are cards touting their use for video purposes (e.g. dash or security cameras that run 24/7). Continuous writes to video files, overwriting each memory cell every X period of time it takes to fill the card, is more punishing than other uses but it could still be far less than the thrashing caused by running an operating system for some tasks.
I've also seen the A1 and A2 classifications for higher IOPS cards, also good for running an OS, but independent of endurance.
Here is a helpful-looking image for selecting between different memory types [1]
[0] https://www.digikey.ca/product-detail/en/swissbit/SFSD1024N1... [1] https://www.cactus-tech.com/assets/images/a/Selector%20Guide...
It's a bit strange to hear that other people have been running Pi's for years with zero issues on SD, but that's definitely not been my experience. Note that I've run a few dozen Pi's that all ran 24/7.
The final solution was to let the Pi boot via USB from an external 2.5 HDD. SSD is best as it consumes less power, but indeed a rust spinner will be fine too.
Consumer cards choose capacity and cost, because that's what sells. Industrial SD cards pick capacity and reliability, but cost at least 4x more than similar consumer cards due to inherent tradeoffs in the hardware/firmware design.
They make high-endurance SD cards that have the same (or better) reliability as SSDs. These are what should be used in any Raspberry Pi that does some non-trivial amount of writing to the disk.
Or boot from USB or Ethernet.
The consumer electronics market is a shit show.
The Pi is pretty much the only one with the sales numbers to justify the cost of a customization, but even that would be a small miracle.
They make high-endurance SD cards that _are_ more reliable and _can_ handle being written to constantly but everyone cheaps out and just gets the cheapest thing on sale from the rainforest retailer and wonders why their cards keep dying.
RPi has binary blobs, but at least they keep supporting boards with software updates
But, I still agree with your point. I basically only buy Raspberry PI's now because the software experience has been terrible with everything else I've tried. (I only learned about Armbian recently, haven't actually tried it out yet.)
https://dl.sendcat.com/Aip36fb6Sn5KBIFQEV8xQ7A0X5sdEf5tX5zrL...
"USB3, Gigabit ethernet (proper), and on the higher variants, it will have a a sata port, second hdmi port (for in or out), and a higher end FGPA"
However:
"not 2019 according to ebden"
[1] https://www.raspberrypi.org/documentation/hardware/raspberry...
Only works if I don't need any local persistence but makes the Pi just work super reliably. Upgrading is as easy as swapping the Linux Kernel image on the fat32 and rebooting.
on boot it self-updates if needed, builds on overlay filesystem w/ the squashed image as the bottom ro layer + tmpfs as top rw layer.
$ sudo su postgres
$ createdb bench_test
$ pgbench -i -s 10 bench_test
$ pgbench -c 10 -j 2 -T 3600 -P 60 bench_test
starting vacuum...end.
progress: 60.0 s, 9192.5 tps, lat 1.088 ms stddev 0.924I was never able to achive more than 3100 tps, even with -march=native -O3 -flto, large wal and shared_buffers, without selinux and THP - I was always bottlenecked by 1 progres process staying in IOWait.
I moved data directory to ramdisk and got: [pgbench -c10 -j 2]: progress: 60.0 s, 26819.3 tps, lat 0.371 ms stddev 0.119. with LA of mere 4.
[pgbench -c30 -j 2]: progress: 60.0 s, 41572.7 tps, lat 0.720 ms stddev 0.390
How do you guys get this crazy performance? Could this be that your RAID fsyncs are not really syncing?
your -c30 is 41.5k
your -c10 is 26.89k, which smokes my 9k
edit: I just misread that and see you moved it to RAMdisk.
What would you like me to do to prove the test is fast because of the SOFTRaid?
With the Minecraft server on: progress: 60.0 s, 6956.5 tps, lat 1.437 ms stddev 1.485
With the Minecraft server off: progress: 60.0 s, 7275.5 tps, lat 1.374 ms stddev 1.975
Looks like not having SoftRaid is killing me. I wish I could test with it on so I can see the comparison of the E3 vs the 7700K, but I would need to re-image.
For fun, a random $5 lowest tier Digital Ocean droplet running a TeamSpeak server (which is using about .07% CPU): progress: 60.0 s, 1507.3 tps, lat 6.631 ms stddev 5.809
And for even more fun, WSL running on my personal/WFH rig - i7-7820X @ 4.8GHz OC, 1TB 950 Pro NVME, 32GB RAM (I let this one run a bit longer as WSL has performance issues, was curious if I would see variance): progress: 60.0 s, 1172.4 tps, lat 8.516 ms stddev 6.017 progress: 120.0 s, 1271.3 tps, lat 7.863 ms stddev 4.817 progress: 180.0 s, 1274.0 tps, lat 7.849 ms stddev 4.943 progress: 240.0 s, 1266.1 tps, lat 7.896 ms stddev 4.875 progress: 300.0 s, 1239.2 tps, lat 8.069 ms stddev 5.211 progress: 360.0 s, 1213.1 tps, lat 8.242 ms stddev 5.447
Ouch! A $3k rig gets outperformed by a $5 DO box.
My iMac was smoking the more expensive DO servers.
$40/mo - 4 GB Memory / 25 GB Disk / NYC1 - Ubuntu 18.04.2 x64
progress: 60.0 s, 3295.3 tps, lat 3.034 ms stddev 1.906
progress: 120.0 s, 3384.4 tps, lat 2.955 ms stddev 2.341
progress: 180.0 s, 3294.9 tps, lat 3.035 ms stddev 2.384
progress: 240.0 s, 3025.3 tps, lat 3.305 ms stddev 2.158
progress: 300.0 s, 3158.5 tps, lat 3.166 ms stddev 2.435
progress: 360.0 s, 3097.8 tps, lat 3.228 ms stddev 3.078
progress: 60.0 s, 4114.9 tps, lat 2.429 ms stddev 7.033
progress: 120.0 s, 4143.9 tps, lat 2.414 ms stddev 6.656
progress: 180.0 s, 3845.5 tps, lat 2.598 ms stddev 7.774
progress: 240.0 s, 4324.4 tps, lat 2.314 ms stddev 7.129
progress: 300.0 s, 3892.1 tps, lat 2.569 ms stddev 8.179
progress: 360.0 s, 4071.5 tps, lat 2.457 ms stddev 7.833
From the article it says the incremental reporting (every 60 seconds) were:
> progress: 540.0 s, 171.8 tps, lat 55.105 ms stddev 946.851
> progress: 600.0 s, 24.6 tps, lat 435.693 ms stddev 2945.727
> progress: 660.0 s, 405.8 tps, lat 24.108 ms stddev 134.692
So they were getting between 24.6 and 405.8 transactions per second.
On the server, he's seeing:
> progress: 60.0 s, 9192.5 tps, lat 1.088 ms stddev 0.924
So the server is doing 9192.5 transactions per second. The test wasn't run as long, but the server is showing much lower latency and standard deviation, as well.
I/O is quite poor on rPIs and that's what PostgreSQL needs more than anything. More than memory or CPU for sure.
The best thing you can ever do for your database is (in this order):
1) Have enough ram to fit your entire dataset (mostly due to joins)
2) Have the best raid card money can buy.
--
An SD card is shocking enough but on the rPI it's going over a USB bridge which takes CPU cycles too!
Still probably performs better than postgresql on WSL; since the I/O is the major bottleneck there too.
pgbench -c 10 -j 2 -T 600 -P 60 bench_test
starting vacuum...end. progress: 60.0 s, 5373.1 tps, lat 1.860 ms stddev 0.709 progress: 120.0 s, 5277.3 tps, lat 1.894 ms stddev 1.383 progress: 180.0 s, 5323.4 tps, lat 1.878 ms stddev 0.733 progress: 240.0 s, 4606.6 tps, lat 2.170 ms stddev 1.508 progress: 300.0 s, 4122.0 tps, lat 2.425 ms stddev 1.517 progress: 360.0 s, 4062.0 tps, lat 2.461 ms stddev 1.532 progress: 420.0 s, 3957.3 tps, lat 2.526 ms stddev 1.598 progress: 480.0 s, 3939.6 tps, lat 2.537 ms stddev 1.599 progress: 540.0 s, 3906.5 tps, lat 2.559 ms stddev 1.627 progress: 600.0 s, 3808.6 tps, lat 2.624 ms stddev 1.747
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10
query mode: simple
number of clients: 10
number of threads: 2
duration: 600 s
number of transactions actually processed: 2662601
latency average = 2.252 ms
latency stddev = 1.435 ms
tps = 4437.570722 (including connections establishing)
tps = 4437.599312 (excluding connections establishing)
So you get roughly an 11x performance improvement by running on a 7 year old desktop processor and rather cheap SSDs. On the other hand, if we say that the Pi setup cost $50 and we estimate the current value of my server at $500, performance/price is basically linear.
depends what the queries are. If they're all for exactly the same data then I/O is gonna be a one off. Even then dbs are usually relatively smart about minimising disk reads and trying to avoid them where possible.
Does this matter anymore? Especially if your CPU is not the bottleneck and you're running internally cached/battery backup SSDs?
I get the idea if you can gain something by offloading the parity calculations, but otherwise?
From the docs:
> PostgreSQL does not protect against correctable memory errors and it is assumed you will operate using RAM that uses industry standard Error Correcting Codes (ECC) or better protection.
https://www.postgresql.org/docs/11/wal-reliability.html
Re: IS ECC RAM really needed?
https://www.postgresql.org/message-id/20070526145214.GA21290...
I use sqlite for full fledged websites with millions of rows with no issue, fast, easy to deploy, easy to move.
Scaling and availability started to kneecap our customers left and right so we migrated to postgres. It was a world of difference. When customers had specials and sent piles of traffic to their stores, they'd stay online the whole time. Everyone slept better.
As much as I disliked that specific use of sqlite, I learned a ton about how awesome it is and came to really love the software behind it. It was also super impressive that it took the company so far, both in terms of the efforts the devs made and sqlite itself.
Generally sharding/HA/DR are difficult problems with any db tech, so yeah, you are definitely right there.
I suspect he basically tested some random SD card's performance.
> Starting with Postgres 10, the default is to give 2 cores to parallel processing. Switching max_parallel_workers_per_gather between 2 and 0 had nearly zero impact on that Pi, either for or against.
With that extra info I'm 99% sure it's I/O limited.
It would be great to know the SDCard speed and maybe see some comparisons based on the SDCard type since the speeds vary quite a bit
Read queries will be cached in RAM and fast (for <1GB database), and write queries will be limited to 500 IOPS, and heavily dependent on how you use transactions and write queries in your database.
Also disabling statistics collecting is the first thing I do when putting a postgresql db on an sd card. Because that causes a lot! of writes.
It's all too easy to dismiss it as an old school engineer being curmudgeonly with a desire to make everyone develop on low-powered hardware. I think there's definite value to telling people to work out the kinks and bottlenecks of their code on a raspberry pi. Especially since those lessons might translate to highly-performing k8s/containers/clusters on lower-power hardware.
I've used RPi1 as a git sever in our company for 5 years with encrypted USB flash drive as storage.
We must have committed at-least a million lines of code into it & we were using it every day.
Except for changing some memory related flags in git, I didn't change much w.r.t to git.
I had another encrypted USB flash drive to which the files were backed up, interestingly this flash drive failed but the primary drive never died till date.
The git server is running 24*7 on RPi1 for past 5 years.
Beecause it is clear from the bad SD card comment that the SD card and PI can influence the speed of the tests.