6,486 karma · joined July 15, 2018
blog: tanelpoder.com
That’s one reason why I haven’t checked out Cloudflare Pages, my (already statically hosted) website will unlikely be DDoSed and I wouldn’t want to impact user experience by adding random browser checks…
- 2 AMD based Compute VMs with 1/8 OCPU and 1 GB memory each.
- 4 Arm-based Ampere A1 cores and 24 GB of memory usable as one VM or up to 4 VMs.
- 2 Block Volumes Storage, 200 GB total.
- 10 GB Object Storage.
- 10 GB Archive Storage.
The ARM infra can be 1 VM with 4 CPUs/24 GB RAM or up to 4 smaller VMs.
I decided to finally write this article, after seeing a yet another "mysterious" case of a missing binary in some Oracle database server. Linux/Bash defaults are ok, but historically (coming from traditional Unix background?), people who engineer environments at least in the Oracle database server world, configure their prompts to some "corporate standard". And sometimes they end up suffixing prompts by a nice-looking ">" character, leading to this problem.
I've also seen someone set their root prompt to `root#>`. Since there's no space between the username and #, the "comment start" is not recognized and the redirection clobbering problem is still there.
Found exactly the same thing (even when we/founders were developing it and knew how to use it). It's so much easier to keep blabbing and that will put the burden on the listener(s) to spend time & focus on playing it.
We didn't have audio transcription, so this may change the game a bit. So, if the sender can't (or doesn't want to) type at the moment, could reply to an otherwise text stream via voice. When we started, iMessage, WhatsApp didn't have asynch voice capability, but now they do - I guess having transcription always enabled would be a differentiator.
But in general (a request that I ignored for too long), you'll have to have texting capability in your app too, otherwise people will gravitate towards whatever allows them to read & type without distracting others with playing audio...
Edit: I guess the summary would be that cash & gold are decoupled from electricity (even if it takes some to create/mine them), but Bitcoin's entire existence depends on continuous availability of (cheap enough) electricity.
I also bought cheap “eBay memory” instead of the more expensive Lenovo offering and had to reseat DIMMs a few times to stop having ECC errors (the memory scrubbing feature is nice).
I would say that on your laptop, you probably wouldn't even notice a difference (as the "rdtsc" timestamp reading operations are pretty efficient & done entirely within a CPU). But with anything that can interact with external hardware million(s) of times per second (heavy SSD I/O in servers and moving large amounts of data over network), may see a minor (but measurable) hit.
In my experience, when large amounts of CPU gets used by interrupt routines (either hardware or software interrupts), that more likely indicates some bug or configuration issue in a device driver or even some faulty hardware issue.
edit: so, running "dmesg" and checking hardware health metrics (mceloc, EDAC) is a reasonable thing to do when interrupt storms & related CPU usage suddenly show up.
When running some application on the box that processes & reduces the dataset (for example some analytics in RDBMS SQL), then the amount of data returned to the world would be much less than 66 GB/s. I have a 1 Gbit AT&T Fibre at my home(office), so could serve quite a lot through that (until AT&T starts complaining about the "unlimited" bandwidth really not being unlimited after some threshold :-)
But when not hosting stuff in a proper data centre with redundant internet connections, connection reliability would probably be the biggest issue. I've not had that many problems with reliability in the home-office (and occasional online training) usage context, but I'm pretty sure there'd be regular "hiccups" if I tried to serve something with high availability from here :-)
Another way of achieving HA together with satisfying disaster recovery requirements is replication (either app level or database log replication, etc). So, no distributed system is necessary unless, you have legit scaling requirements.
If you work on ERP-like databases for traditional Fortune 500-like companies, few people run such "sacred monolith" applications on modern distributed NoSQL databases, it's all Oracle, MSSQL or some Postgres nowadays. Data warehouses used to be all Oracle, Teradata too - although these DBs support some cluster scale-out, they're still "sacred monoliths" from a different era (they are still doing - what they were designed for - very well). Now of course Snowflake, BigQuery, etc are taking over the DW/analytics world for new greenfield projects, existing systems usually stay as they are due to lock-in & extremely high cost of rewriting decades of existing reports and apps.
When I think about Optane, I think about optimizing for low latency where it's needed and not that much about bandwidth of large ops.
Btw, even the DIMMs have dedicated fans and enclosure (one per 4 DIMMs) on the P620.
1) Learning & researching capabilities of modern HW
2) Running RDBMS stress tests (until breaking point), Oracle, Postgres+TimescaleDB, MySQL, probably ScyllaDB soon too
3) Why? As a performance troubleshooter consultant+trainer, I regularly have to reproduce complex problems that show up only under high concurrency & load - stuff that you can't just reproduce in a VM in a laptop.
4) Fun - seeing if the "next gen" hardware's promised performance is actually possible!
FYI I have some videos from my past complex problem troubleshooting adventures, mostly Oracle stuff so far and some Linux performance troubleshooting:
I mean, currently OLTP RDBMS engines tend to use 4k, 8k (and some) 16k block size and when doing completely random I/O (or, say traversing an index on customer_id that now needs to read random occasional customer orders across years of history). So you may end up reading 1000 x 8 kB blocks just to read 1000 x 100B order records "randomly" scattered across the table from inserts done over the years.
Optane persistent memory can do small, cache line sized I/O I understand, but that's a different topic. When being able to do random 512B I/O on "commodity" NVMe SSDs efficiently, this would open some interesting opportunities for retrieving records that are scattered "randomly" across the disks.
edit: to answer your question, I used 10 separate fio commands with numjobs=3 or 4 for each and randrepeat was set to default.
https://images-eu.ssl-images-amazon.com/images/I/914ckzwNMpS...
When I have more time again, I'll run fio with the SPDK plugin on my kit too. And would be interested in seeing what happens when doing 512B random I/Os?