Skip to content

Category: Data Centers

Threads vs. Watts

So I have been testing, again.

My hapless test subject this time is a Dell Box, an R630.

It has a comfortable 384GB of memory, one of two 25 GBit/s ports active, and it comes with two E5-2690v4 CPUs. That gives it 14 cores per die, 28 cores in total, or with hyperthreading, 56 threads.

$ cat /proc/cpuinfo | grep 'model name' | uniq -c
56 model name : Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz
$ ./mprime -v
Mersenne Prime Test Program: Linux64,Prime95,v28.10,build 1
3 Comments

The attack of the killer microseconds

In the Optane article I have been writing about how persistent bit-addressable memory will be changing things, and how network latencies may becoming a problem.

The ACM article Attack of the Killer Microseconds has another, more general take on the problem. It highlights how we are prepared in our machines to deal with very short delays such as nanoseconds, and how we are also prepared to deal with very long delays such as milliseconds. It’s the waits inbetween, the network latencies, sleep state wakeups and SSD access waits, that are too short to do something else and too long to busy wait in a Spinlock.

1 Comment

BFQ is coming…

LWN reports that the 4.11 merge window opens. Among other things, Maik Zumstrull reminds us, we get

The multiqueue block layer finally has support for I/O scheduling. That is useful in its own right, but the real news is that it enables the merging of the long-awaited BFQ I/O scheduler. That, says block maintainer Jens Axboe, “should be ready for 4.12”.

Of course, if you are on a LTS release of a Linux kernel, it’s unlikely that you will profit from this any time soon.

Leave a Comment

Post like it is 2015

Following a great idea from their friends at GitLab, Soup.io loses all postings since 2015 because of malfunctioning backups. They write:

We had a big database crash, and the backups we had were corrupted.
The only working backup was from 2015.

Also, TIL soup.io still exists. Meanwhile, Gitlab posted a blameless postmortem. You can read it online, and they write:

Improving Recovery Procedures

[…]
9. Automated testing of recovering PostgreSQL database backups (#1102)
[…]

Does your database backup successfully restore? Are you sure? Are you testing this?

Remember these words of wisdom:

Nobody wants backup.
Everybody wants restore.
— Martin Seeger

1 Comment

Using a blade center chassis to make Döner Kebap

I had the opportunity to play with a Blade Center Chassis with 16 Blades, each of them a Dual-E5 2690v4, so 56 threads (28 cores) times 16.

$ mkdir mprime; \
] cd mprime; \
] wget http://www.mersenne.org/ftp_root/gimps/p95v2810.linux64.tar.gz; \
] tar xvzf p95v2810.linux64.tar.gz; \
] ./mprime -m

running with “stress test only”, “mode 1 – small FFT” and 56 cores gets me quite a bit of power consumption.

Idle Blades is being reported as 140W, busy blades are 400W.

Images below the fold.

2 Comments

Scaleway adds Servers for Intensive Workloads

This blog is hosted at Scaleway

Scaleway lets me know that they added new server types for large workloads.

The the sizes are ten and twelve core machines with 60/120 GB memory respectively and large SSD. Bandwidth is a Gigabit/s and is unmetered. Additional storage volumes can be attached.

So if you are asking where to put your really large MySQL, now you know.

1 Comment

Google vs. your data

Hooray, EU data protection authorities confirm compliance of Google Cloud commitments for international data flows! exclaims Google.

But on the other hand, Google ordered to hand over foreign emails to FBI, unlike Microsoft.

With legal instabilities and conflicting signals like these, are you running your crap in a public cloud owned and operated by a US company?

You probably should, it’s still better infra than you could create yourself. But the legal nonframework around it – it is not helping at all.

2 Comments