!CcTBuBritXGywOEGWJ:matrix.org

NixOS Binary Cache Self-Hosting

169 Members
About how to host a very large-scale binary cache and more58 Servers

Load older messages


SenderMessageTime
5 Mar 2024
@edef1c:matrix.orgedefwe're serving like 375Mbit/s to Fastly in the peak minute on a day chosen by Fair Dice Roll™04:03:53
@edef1c:matrix.orgedefnot sure how to meaningfully turn these things into iops numbers just because that depends on various factors04:05:27
@edef1c:matrix.orgedefclickhouse is refusing to deal with S3 wildcards for some reason and i haven't quite chased down why yet04:06:41
@edef1c:matrix.orgedefi'm just taking a request that completed in that minute to have fully executed in that minute but i think that shakes out to a slightly upwards biased estimator if anything04:08:29
@edef1c:matrix.orgedefokay i just need to upgrade clickhouse on the EC2 data box i think04:09:57
@edef1c:matrix.orgedef * we're serving like 375Mbit/s of compressed NARs to Fastly in the peak minute on a day chosen by Fair Dice Roll™04:10:45
@edef1c:matrix.orgedefi'm focusing on the NAR serving because that's the actual meat of it, the narinfos are only like 90G of stuff04:11:17
@edef1c:matrix.orgedefwe also have a few other file types but they're mostly pretty marginal04:11:52
@edef1c:matrix.orgedef
WHERE NOT key REGEXP '^[0123456789abcdfghijklmnpqrsvwxyz]{32}\.narinfo$'
  AND NOT key REGEXP '^[0123456789abcdfghijklmnpqrsvwxyz]{32}\.ls(\.xz)?$'
  AND NOT key REGEXP '^[0123456789abcdfghijklmnpqrsvwxyz]{32}-[a-zA-Z0-9+\-_?=][a-zA-Z0-9+\-_?=.]*\.ls$'
  AND NOT key REGEXP '^nar/[0123456789abcdfghijklmnpqrsvwxyz]{52}\.nar\.(bz2|xz)$'
  AND NOT key REGEXP '^log/[0123456789abcdfghijklmnpqrsvwxyz]{32}-[a-zA-Z0-9+\-_?=][a-zA-Z0-9+\-_?=.]*\.drv$'
  AND NOT key REGEXP '^debuginfo/[0-9a-f]{40}$'
  AND NOT key REGEXP '^debuginfo/[0-9a-f]{16}$'
  AND NOT key IN ('.well-known/pki-validation/gsdv.txt', 'nix-cache-info', 'index.html', 'binary-cache/', 'error-pages/403', 'error-pages/404')
04:12:00
@edef1c:matrix.orgedef^ that yields an empty result set if applied over the S3 inventory04:12:33
@edef1c:matrix.orgedefdebuginfo is for dwarffs which basically nobody uses, i think the 64-bit ones are even more dead, logfiles aren't a huge traffic driver either, .ls files are used by nar-index iirc but we don't have very much of those04:13:27
@edef1c:matrix.orgedef * debuginfo is for dwarffs which basically nobody uses, i think the 64-bit ones are even more dead, logfiles aren't a huge traffic driver either, .ls files are used by nix-index iirc but we don't have very much of those04:13:45
@edef1c:matrix.orgedefbasically at peak we're serving like a gigabit of NARs04:15:22
@edef1c:matrix.orgedef * basically at peak we're serving like a gigabit per second of NARs04:15:34
@edef1c:matrix.orgedef

that is, the following query yields 7400044328 bytes/min ≈ 1 Gbit/s

SELECT max(bytes_per_minute)
FROM
(
    SELECT
        toStartOfMinute(fromUnixTimestamp(timestamp)) AS minute,
        SUM(bytes_sent) AS bytes_per_minute
    FROM s3('s3://nix-archeologist/nix-cache-bucket-logs/*.parquet', Parquet, 'key String, http_status Int64, bytes_sent Int64, user_agent String, operation String, requester String, timestamp UInt32')
    WHERE startsWith(key, 'nar/') AND (requester = 'arn:aws:iam::080433136561:user/fastly-cache-access') AND (http_status IN (200, 206))
    GROUP BY minute
)
04:17:09
@nh2:matrix.orgnh2
In reply to @edef1c:matrix.org
easy stats: over the last 24h we've served 2.1TiB from all our S3 buckets, uploaded 491G, in ~30M requests

Thanks!

So mean is 24 MB/s, 350 req/s.
That traffic will be very easy with 6 10 Gbit/s servers.
The IOPS should work, EC 6=4+2 should give 1500 reads IO/s, so we'd have 5x margin over the mean.

Probably a good amount of that can also be cached away from the HDDs as many people will be likely requesting latest nixos-* branches, and fewer people older, pinned branches.

04:19:30
@edef1c:matrix.orgedefthat number is coming from the S3 dash, and is over all nixos.org buckets04:20:38
@edef1c:matrix.orgedefbut it's a 24h sample, my other numbers are coming from a few months worth of data04:21:11
@nh2:matrix.orgnh2 edef: Can you query the number of files / the distribution/histogram of their sizes? A weakness of Ceph is large amounts of small files. 04:21:14
@nh2:matrix.orgnh2 * edef: Can you query the number of files / the distribution/histogram of their sizes? A weakness of Ceph on HDDs is large amounts of small files. 04:21:29
@edef1c:matrix.orgedefsure, i can draw you some histograms04:21:59
@edef1c:matrix.orgedefi can tell you up front that our biggest source of small files is the narinfos though04:22:20
@edef1c:matrix.orgedefbut there's only like 90G of that so we can serve that from SSD quite easily04:23:08
@edef1c:matrix.orgedeflike, we can solve small file serving in a lot of easy ways i think04:24:02
@edef1c:matrix.orgedef
In reply to @nh2:matrix.org

Thanks!

So mean is 24 MB/s, 350 req/s.
That traffic will be very easy with 6 10 Gbit/s servers.
The IOPS should work, EC 6=4+2 should give 1500 reads IO/s, so we'd have 5x margin over the mean.

Probably a good amount of that can also be cached away from the HDDs as many people will be likely requesting latest nixos-* branches, and fewer people older, pinned branches.

from my larger sample, mean ~16MiB/s, median ~14MiB/s
04:27:05
@edef1c:matrix.orgedef
In reply to @nh2:matrix.org
edef: Can you query the number of files / the distribution/histogram of their sizes? A weakness of Ceph on HDDs is large amounts of small files.
we have ~47M NARs under 4k
04:29:15
@edef1c:matrix.orgedefhow much of those we're serving is a harder question, fastly's segmented caching makes it a bit weird to query that without a big painful join04:30:41
@edef1c:matrix.orgedefwill pull you some histograms in a bit, first going to take a break to eat/recaffeinate04:31:39
@nh2:matrix.orgnh2
In reply to @edef1c:matrix.org
from my larger sample, mean ~16MiB/s, median ~14MiB/s
That is nice and large, should make it easy.
04:36:00
@edef1c:matrix.orgedefnote that i've given you zero information about I/O sizes so far04:36:36

There are no newer messages yet.


Back to Room ListRoom Version: 10