Looking for 3 servers in Dallas

imok · July 18

Hi!
I'm looking for 3 (or 4) servers in Dallas, US.

For each one:

Different node.
RAM 4gb
CPU: 2+ cores. Something more powerful than an E5v4.
Storage: 80gb - 100gb SSD or NVMe.
Network: 1gbps minimun
Private network would be nice.
$5/m per server is fine?

I'm trying to build a database cluster because I like to suffer.

My compute resources are in Dallas so I can't use another location. Unless I move my dedicated servers... but where? and it would more expensive these days... can we kill AI?

rpqu · July 18

Consider @DartNode @georgedatacenter @crunchbits

skorous · July 18

What sort of db cluster you setting up that won't fit on your existing dedis?

qps · July 18

@imok Why did you choose Dallas to begin with? Where are you located?

imok · July 18

@skorous said:
What sort of db cluster you setting up that won't fit on your existing dedis?

I don't want everything to die at the same time. And I only have 2 dedis in Dallas. I want to use this db cluster for all my apps.

@qps said:
@imok Why did you choose Dallas to begin with? Where are you located?

In Peru. Lowest latency after Miami.

Dallas was the cheapest like five years ago, I got a few good deals for the hardware and it's still there. Lots of storage, RAM and not-so-ancient CPUs, but they are almost full and I'm just waiting for the drives to fail. After that, I will be moving my stuff to another city, maybe.

imok · July 18

@imok said: Lowest latency after Miami.

Ok it looks like Virginia is the 2nd lowest now. Something changed, ping increased.

SMARTHOST · July 18

We can do something for you on Ryzen nodes in Dallas TX, but may just be a hair more expensive.
Reach out to us at [email protected]

~ SMARTHOST

oloke · July 18

Try asking @serverpoint for some custom deal.
They offer VPS servers with private network in Dallas, USA.

https://www.serverpoint.com/en/vps-hosting/

teamacc · July 18

@MikeA might be out of your budget unless he does a special

MikeA · July 18

@teamacc said:
@MikeA might be out of your budget unless he does a special

I'm out of stock in Dallas practically, and I can't do very cheap deals now with memory prices, since I only build new hardware. Either way I don't do private networking unfortunately. Thanks though.

AK_KWH · July 19

@imok said:
Hi!
I'm looking for 3 (or 4) servers in Dallas, US.

For each one:

Different node.

RAM 4gb

CPU: 2+ cores. Something more powerful than an E5v4.

Storage: 80gb - 100gb SSD or NVMe.

Network: 1gbps minimun

Private network would be nice.

$5/m per server is fine?

I'm trying to build a database cluster because I like to suffer.

My compute resources are in Dallas so I can't use another location. Unless I move my dedicated servers... but where? and it would more expensive these days... can we kill AI?

we have In Houston Texas 10Gbps with Gold 6152
we can do 8$ a month
4GB RAM
80GB SSD
2TB@10Gbps

caasify · July 19

We provider Dallas cloud VPS on caasify, but our pricing is higher than your request. You can opt for a yearly payment to get a discount.

imok · July 20

Thank you all!

Got a server from @serverpoint, not the fastest but cheap enough I'll test it tomorrow and see if I would get the additional 3.

Intel Xeon E5 v4
4 vCPUs at 2.1 GHz
8 GB RAM
100 GB fast storage
10 TB of data transfer per month
1 IPv4 address
1 Gbps network port

BTW, I'm going to try PIGSTY https://pigsty.io/

arirang · July 20

@imok said:
Thank you all!

Got a server from @serverpoint, not the fastest but cheap enough I'll test it tomorrow and see if I would get the additional 3.

Intel Xeon E5 v4
4 vCPUs at 2.1 GHz
8 GB RAM
100 GB fast storage
10 TB of data transfer per month
1 IPv4 address
1 Gbps network port

BTW, I'm going to try PIGSTY https://pigsty.io/

I’m afraid their disk speed isn’t enough for an etcd cluster. I use Patroni with etcd myself.

imok · July 20

@arirang said:

@imok said:
Thank you all!

Got a server from @serverpoint, not the fastest but cheap enough I'll test it tomorrow and see if I would get the additional 3.

Intel Xeon E5 v4
4 vCPUs at 2.1 GHz
8 GB RAM
100 GB fast storage
10 TB of data transfer per month
1 IPv4 address
1 Gbps network port

BTW, I'm going to try PIGSTY https://pigsty.io/

I’m afraid their disk speed isn’t enough for an etcd cluster. I use Patroni with etcd myself.

Sad. I'm not an expert with that. What speed should I be looking for?

YABS from the new server:

# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
#              Yet-Another-Bench-Script              #
#                     v2026-07-03                    #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

Mon Jul 20 12:05:03 CDT 2026

Basic System Information:
---------------------------------
Uptime     : 0 days, 12 hours, 18 minutes
Processor  : Intel(R) Xeon(R) CPU E5-2699A v4 @ 2.40GHz
CPU cores  : 4 @ 2399.988 MHz
AES-NI     : ✔ Enabled
VM-x/AMD-V : ✔ Enabled
RAM        : 7.8 GiB
Swap       : 128.0 MiB
Disk       : 98.1 GiB
Distro     : Debian GNU/Linux 12 (bookworm)
Kernel     : 6.1.0-27-amd64
VM Type    : MICROSOFT
IPv4/IPv6  : ✔ Online / ❌ Offline

IPv4 Network Information:
---------------------------------
ISP        : ServerPoint.com
ASN        : AS26277 ServerPoint.com
Host       : Dallas TX Datacenter
Location   : Dallas, Texas (TX)
Country    : United States

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ---- 
Read       | 74.17 MB/s   (18.1k) | 425.72 MB/s   (6.4k)
Write      | 74.36 MB/s   (18.1k) | 427.97 MB/s   (6.5k)
Total      | 148.53 MB/s  (36.2k) | 853.69 MB/s  (13.0k)
           |                      |                     
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ---- 
Read       | 518.31 MB/s    (988) | 500.91 MB/s    (477)
Write      | 545.85 MB/s   (1.0k) | 534.27 MB/s    (509)
Total      | 1.06 GB/s     (2.0k) | 1.03 GB/s      (986)

iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider        | Location (Link)           | Send Speed      | Recv Speed      | Ping           
-----           | -----                     | ----            | ----            | ----           
Clouvider       | London, UK (10G)          | 746 Mbits/sec   | 650 Mbits/sec   | 102 ms         
Eranium         | Amsterdam, NL (100G)      | 905 Mbits/sec   | 2.59 Gbits/sec  | 106 ms         
Uztelecom       | Tashkent, UZ (10G)        | busy            | 2.67 Gbits/sec  | 198 ms         
Leaseweb        | Singapore, SG (10G)       | 770 Mbits/sec   | 3.83 Gbits/sec  | 235 ms         
Clouvider       | Los Angeles, CA, US (10G) | busy            | 4.30 Gbits/sec  | 37.8 ms        
Leaseweb        | NYC, NY, US (10G)         | 979 Mbits/sec   | 5.31 Gbits/sec  | 38.3 ms        
Edgoo           | Sao Paulo, BR (1G)        | 872 Mbits/sec   | 945 Mbits/sec   | 135 ms         

Geekbench 6 Benchmark Test:
---------------------------------
Test            | Value                         
                |                               
Single Core     |                               
Multi Core      |                               
Full Test       | https://browser.geekbench.com/v6/cpu/18769019

YABS completed in 13 min 52 sec

imok · July 20

It seems @arirang is correct. Disk speed is not enough, maybe because it's Ceph.

/usr/lib/postgresql/15/bin/pg_test_fsync -f /tmp/test_wal -s 3
3 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                       246.266 ops/sec    4061 usecs/op
        fdatasync                           240.257 ops/sec    4162 usecs/op
        fsync                                86.970 ops/sec   11498 usecs/op
        fsync_writethrough                              n/a
        open_sync                           114.273 ops/sec    8751 usecs/op

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                       169.889 ops/sec    5886 usecs/op
        fdatasync                           350.292 ops/sec    2855 usecs/op
        fsync                               119.886 ops/sec    8341 usecs/op
        fsync_writethrough                              n/a
        open_sync                            58.619 ops/sec   17059 usecs/op

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
         1 * 16kB open_sync write           117.486 ops/sec    8512 usecs/op
         2 *  8kB open_sync writes           53.329 ops/sec   18751 usecs/op
         4 *  4kB open_sync writes           28.866 ops/sec   34643 usecs/op
         8 *  2kB open_sync writes           15.047 ops/sec   66458 usecs/op
        16 *  1kB open_sync writes            7.296 ops/sec  137070 usecs/op

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written on a different
descriptor.)
        write, fsync, close                 113.405 ops/sec    8818 usecs/op
        write, close, fsync                 118.875 ops/sec    8412 usecs/op

Non-sync'ed 8kB writes:
        write                            723766.195 ops/sec       1 usecs/op

Sad.

arirang · July 20

@imok said:
It seems @arirang is correct. Disk speed is not enough, maybe because it's Ceph.

Sad.

To be honest, it’s hard to get consistently stable disk performance in a virtualized environment. Even for a small cluster, I’d want to see at least 500 IOPS sustained. If you run a 10-minute test and the IOPS periodically drop or spike, that’s not ideal for an etcd cluster.

That said, it won’t necessarily cause frequent leader changes. However, if the leader experiences enough instability, a new leader election may be triggered, and you’ll likely start seeing warning messages accumulate in the logs.

A high 4K score in YABS doesn’t necessarily mean the storage is suitable for etcd. You can still encounter IOPS drops and latency spikes, so it’s better to validate it using the command below or a dedicated etcd benchmarking tool.

fio --name=etcd_fsync_test \
  --filename=etcd_test_file \
  --rw=write \
  --ioengine=libaio \
  --bs=4k \
  --iodepth=1 \
  --fdatasync=1 \
  --direct=1 \
  --size=5G \
  --runtime=600 \
  --time_based \
  --rate_iops=1000 \
  --group_reporting

For etcd, the 99th percentile and maximum latency values are much more important than the average.

I’ve tested quite a few providers, and only a handful consistently met that requirement. That said, even they occasionally have spikes—it’s just the nature of virtualized environments.

imok · July 21

Not sure if the VPS from ServerPoint is transferable. If anybody knows and wants it, let me know.

It's not suitable for my use case but it seems good for the price.

Not_Oles · July 22

@imok @arirang

I don't understand much about kubernetes and etcd but I decided to try running a modified test command on the server I recently got from QuickPacket (s/libaio/sync and other changes cuz it's running NetBSD -- not sure about whether that ioengine change or other changes make an important difference):

qp$ date
Wed Jul 22 03:18:49 UTC 2026
qp$ fio --name=etcd_fsync_test \
>   --filename=etcd_test_file \
>   --rw=write \
>   --ioengine=sync \
>   --thread=1 \
>   --bs=4k \
>   --fdatasync=1 \
>   --size=10M \
>   --runtime=10 \
>   --time_based \
>   --rate_iops=1000 \
>   --group_reporting

etcd_fsync_test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=sync, iodepth=1
fio-3.19
Starting 1 thread
etcd_fsync_test: Laying out IO file (1 file / 10MiB)
Jobs: 1 (f=1), 0-1000 IOPS: [W(1)][100.0%][w=4003KiB/s][w=1000 IOPS][eta 00m:00s]
etcd_fsync_test: (groupid=0, jobs=1): err= 0: pid=25496: Wed Jul 22 03:19:05 2026
  write: IOPS=1000, BW=4000KiB/s (4096kB/s)(39.1MiB/10001msec)
    clat (usec): min=20, max=252, avg=25.58, stdev=11.10
     lat (usec): min=21, max=253, avg=26.67, stdev=11.10
    clat percentiles (nsec):
     |  1.00th=[20608],  5.00th=[21120], 10.00th=[21120], 20.00th=[21120],
     | 30.00th=[21120], 40.00th=[21120], 50.00th=[21120], 60.00th=[21376],
     | 70.00th=[21376], 80.00th=[24960], 90.00th=[32640], 95.00th=[52992],
     | 99.00th=[69120], 99.50th=[70144], 99.90th=[81408], 99.95th=[84480],
     | 99.99th=[97792]
   bw (  KiB/s): min= 4000, max= 4007, per=100.00%, avg=4003.44, stdev= 3.55, samples=18
   iops        : min= 1000, max= 1001, avg=1000.50, stdev= 0.51, samples=18
  lat (usec)   : 50=90.65%, 100=9.34%, 500=0.01%
  fsync/fdatasync/sync_file_range:
    sync (usec): min=142, max=374, avg=213.32, stdev=25.73
    sync percentiles (usec):
     |  1.00th=[  165],  5.00th=[  167], 10.00th=[  204], 20.00th=[  204],
     | 30.00th=[  206], 40.00th=[  206], 50.00th=[  206], 60.00th=[  206],
     | 70.00th=[  208], 80.00th=[  221], 90.00th=[  241], 95.00th=[  262],
     | 99.00th=[  314], 99.50th=[  338], 99.90th=[  347], 99.95th=[  347],
     | 99.99th=[  375]
  cpu          : usr=47.75%, sys=36.81%, ctx=20865, majf=0, minf=36
  IO depths    : 1=200.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,10001,0,0 short=10000,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=4000KiB/s (4096kB/s), 4000KiB/s-4000KiB/s (4096kB/s-4096kB/s), io=39.1MiB (40.0MB), run=10001-10001msec

If I understand right, the median score was [206] 0.20 milliseconds and the 99th percentile was [314] 0.31 milliseconds. Apparently the production standard might be under 2.0 milliseconds, so it looks like maybe the test completed within about one tenth of the allowed time? Is what was done here at all meaningful?

For this month and a few days more, I also have another server in Santa Clara, running Debian. If you want to try something on either server or on both, please let me know.

imok · July 24

@qps you do colo in Ashburn? I have two Dl360p gen9, 1U, dual E5-2699v3, 8x SSD that I'm interested to move in there

qps · July 24

@imokPlatinum said: @qps you do colo in Ashburn? I have two Dl360p gen9, 1U, dual E5-2699v3, 8x SSD that I'm interested to move in there

Yes, DM me to discuss.

serverpoint · July 25

@imok said:
Not sure if the VPS from ServerPoint is transferable. If anybody knows and wants it, let me know.

It's not suitable for my use case but it seems good for the price.

You can request a refund. We'll grant since the server doesn't suit your needs.

I am curious though. How busy is your etcd database? Hundreds of megabits per second? We control the IO rate in order to reduce possible abuse.

Be aware also that we offer dedicated servers in Dallas, with fast RAID storage and also NVMe drives. That could work for you, and we do provide private networking between your dedicated machines.

imok · July 26

@serverpoint said:

@imok said:
Not sure if the VPS from ServerPoint is transferable. If anybody knows and wants it, let me know.

It's not suitable for my use case but it seems good for the price.

You can request a refund. We'll grant since the server doesn't suit your needs.

That's awesome but no worries.

I am curious though. How busy is your etcd database? Hundreds of megabits per second? We control the IO rate in order to reduce possible abuse.

Certainly it won't be a busy DB. I'm trying to make a diagnosis with multiple benchmarks before buying 3 servers and starting all the work. I'm trying to prevent errors but now I see it can be a way to learn. Maybe I'll try.

We control the IO rate in order to reduce possible abuse.

Are you just mentioning the state of the environment, or do you mean etcd can get me into trouble with shared resources?

Be aware also that we offer dedicated servers in Dallas, with fast RAID storage and also NVMe drives. That could work for you, and we do provide private networking between your dedicated machines.

Nice, but I can't afford those prices 😅

serverpoint · July 26

We control the IO rate in order to reduce possible abuse.

Are you just mentioning the state of the environment, or do you mean etcd can get me into trouble with shared resources?

Just mentioning why you see the test results you saw. Our storage cluster are certainly capable of far more than that, but each VM has a specific iops/IO rate applied.

I assume though most of the data in etcd would be held in RAM for reading, thus, disk IO rate doesn't matter much; RAM would matter more. Unless you are using etcd to mostly do writing at a rate of thousands of iops or hundreds of megabits per second.

arirang · July 26

@serverpoint said:

We control the IO rate in order to reduce possible abuse.

Are you just mentioning the state of the environment, or do you mean etcd can get me into trouble with shared resources?

Just mentioning why you see the test results you saw. Our storage cluster are certainly capable of far more than that, but each VM has a specific iops/IO rate applied.

I assume though most of the data in etcd would be held in RAM for reading, thus, disk IO rate doesn't matter much; RAM would matter more. Unless you are using etcd to mostly do writing at a rate of thousands of iops or hundreds of megabits per second.

Etcd is not an in-memory database. Every Raft heartbeat and consensus write requires a synchronous fdatasync to disk. If disk I/O latency spikes due to strict rate limits, the leader misses its heartbeat interval, triggering constant re-elections regardless of available RAM.

No offense, I already run several VMs with you, but due to these per-VM I/O limits, they aren't quite suitable for running a latency-sensitive etcd cluster."

arirang · July 26

@arirang said:

@serverpoint said:

We control the IO rate in order to reduce possible abuse.

Are you just mentioning the state of the environment, or do you mean etcd can get me into trouble with shared resources?

Just mentioning why you see the test results you saw. Our storage cluster are certainly capable of far more than that, but each VM has a specific iops/IO rate applied.

I assume though most of the data in etcd would be held in RAM for reading, thus, disk IO rate doesn't matter much; RAM would matter more. Unless you are using etcd to mostly do writing at a rate of thousands of iops or hundreds of megabits per second.

Etcd is not an in-memory database. Every Raft heartbeat and consensus write requires a synchronous fdatasync to disk. If disk I/O latency spikes due to strict rate limits, the leader misses its heartbeat interval, triggering constant re-elections regardless of available RAM.

No offense, I already run several VMs with you, but due to these per-VM I/O limits, they aren't quite suitable for running a latency-sensitive etcd cluster."

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 76.96 MB/s   (18.7k) | 431.56 MB/s   (6.5k)
Write      | 77.17 MB/s   (18.8k) | 433.83 MB/s   (6.6k)
Total      | 154.14 MB/s  (37.6k) | 865.39 MB/s  (13.2k)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 718.12 MB/s   (1.3k) | 745.16 MB/s    (710)
Write      | 756.28 MB/s   (1.4k) | 794.79 MB/s    (757)
Total      | 1.47 GB/s     (2.8k) | 1.53 GB/s     (1.4k)

YABS completed in 56 sec

etcd_fsync_test: Laying out IO file (1 file / 5120MiB)
Jobs: 1 (f=1), 0-1000 IOPS: [W(1)][100.0%][w=604KiB/s][w=151 IOPS][eta 00m:00s]
etcd_fsync_test: (groupid=0, jobs=1): err= 0: pid=1530: Sun Jul 26 06:30:46 2026
  write: IOPS=134, BW=539KiB/s (551kB/s)(316MiB/600002msec); 0 zone resets
    slat (usec): min=22, max=4276, avg=44.96, stdev=24.62
    clat (usec): min=1131, max=169902, avg=2445.90, stdev=2874.65
     lat (usec): min=1163, max=169948, avg=2490.86, stdev=2876.11
    clat percentiles (usec):
     |  1.00th=[ 1336],  5.00th=[ 1434], 10.00th=[ 1483], 20.00th=[ 1565],
     | 30.00th=[ 1631], 40.00th=[ 1680], 50.00th=[ 1762], 60.00th=[ 1844],
     | 70.00th=[ 2008], 80.00th=[ 2376], 90.00th=[ 3621], 95.00th=[ 5407],
     | 99.00th=[13960], 99.50th=[20317], 99.90th=[39584], 99.95th=[47449],
     | 99.99th=[64750]
   bw (  KiB/s): min=  136, max=  777, per=99.89%, avg=538.81, stdev=129.70, samples=1199
   iops        : min=   34, max=  194, avg=134.65, stdev=32.40, samples=1199
  lat (msec)   : 2=69.82%, 4=21.82%, 10=6.60%, 20=1.24%, 50=0.48%
  lat (msec)   : 100=0.04%, 250=0.01%
  fsync/fdatasync/sync_file_range:
    sync (msec): min=3, max=463, avg= 7.38, stdev= 5.38
    sync percentiles (msec):
     |  1.00th=[    5],  5.00th=[    5], 10.00th=[    5], 20.00th=[    6],
     | 30.00th=[    6], 40.00th=[    6], 50.00th=[    6], 60.00th=[    7],
     | 70.00th=[    7], 80.00th=[    9], 90.00th=[   11], 95.00th=[   15],
     | 99.00th=[   30], 99.50th=[   40], 99.90th=[   63], 99.95th=[   74],
     | 99.99th=[  103]
  cpu          : usr=0.31%, sys=1.03%, ctx=161666, majf=0, minf=12
  IO depths    : 1=200.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,80786,0,0 short=80786,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=539KiB/s (551kB/s), 539KiB/s-539KiB/s (551kB/s-551kB/s), io=316MiB (331MB), run=600002-600002msec

Disk stats (read/write):
  vda: ios=6/243059, merge=0/162079, ticks=14/621628, in_queue=643887, util=96.61%

YABS results look fantastic on paper (37k IOPS, 1.5 GB/s throughput). However, etcd requires synchronous fdatasync=1 writes (iodepth=1). A 10-minute actual fdatasync test reveals the real storage performance:

Throughput: Achieved only 134 IOPS (requested 1,000 IOPS) with 96.6% disk utilization.
Sync Latency: Average of 7.38 ms, P99 at 30 ms, and max spikes reaching 463 ms.

Of course, we could adjust the settings and increase the heartbeat timeout to prevent immediate leader loss.
However, in actual production, critical operations like API responses and etcd compaction could still freeze the entire cluster. Since the disk utilization is already hitting nearly 100% at a mere 130–150 IOPS, there is zero headroom left when those heavy background tasks kick in.

MikeA · July 26

Based on the last replies here regarding I/O use it seems like a dedicated server is the best option, not a virtual/shared environment for high disk I/O.

serverpoint · July 26

@arirang said:

@serverpoint said:

We control the IO rate in order to reduce possible abuse.

Are you just mentioning the state of the environment, or do you mean etcd can get me into trouble with shared resources?

Just mentioning why you see the test results you saw. Our storage cluster are certainly capable of far more than that, but each VM has a specific iops/IO rate applied.

I assume though most of the data in etcd would be held in RAM for reading, thus, disk IO rate doesn't matter much; RAM would matter more. Unless you are using etcd to mostly do writing at a rate of thousands of iops or hundreds of megabits per second.

Etcd is not an in-memory database. Every Raft heartbeat and consensus write requires a synchronous fdatasync to disk. If disk I/O latency spikes due to strict rate limits, the leader misses its heartbeat interval, triggering constant re-elections regardless of available RAM.

No offense, I already run several VMs with you, but due to these per-VM I/O limits, they aren't quite suitable for running a latency-sensitive etcd cluster."

None taken. I was just curious. I would have thought that for reading, Linux would cache most of the data in RAM, which is what I was discussing earlier.

Let us know if you wish to use it or cancel it. We'll gladly send a refund your way.

Looking for 3 servers in Dallas

Comments