Prateek Jain’s Post

This is a fantastic article, we tried todo this at Mailgun, but ultimately failed. We were unable to effectively communicate this fact. > Our goal is to forecast a customer’s CPU utilization, but we can’t just train a model based on recent fluctuations of CPU, because that would create a circular dependency: if we predict a CPU spike and scale accordingly, we eliminate the spike, invalidating the forecast. The ability to effectively communicate concepts is an underappreciated art. https://lnkd.in/gkeZ5MnQ

A few minutes ago, we published updated guidance on the hard limit in SQL Server for 64 logical cores per NUMA node. If you have a VM or physical server with more than 64 logical cores per NUMA node, you can turn off simultaneous multithreading (SMT, which Intel calls Hyper-Threading), or reduce the number of logical cores per NUMA node using a BIOS configuration, depending on your CPU vendor (Intel or AMD). https://lnkd.in/dpvamCvX

Umbra: A Disk-Based System with In-Memory Performance "On the other hand, SSDs have achieved astonishing improvements over the past years. A modern 2 TB M.2 SSD can read with about 3.5 GB/s, while costing only $500. In comparison, 2 TB of server DRAM costs about $20 000, i.e. a factor of 40 more. By placing multiple SSDs into one machine we can get excellent read bandwidths at a fraction of the cost of a pure DRAM solution." https://lnkd.in/guCEFY8r

Microsoft SQL Server has some "hard limits", aka "Magic Numbers", that are conscious design choices. They are not bugs! 64 logical cores/NUMA node is one more that goes into my list. Others that I have in my list are --> @@NESTLEVEL --> @@TRANCOUNT They used to be limited to 16 in legacy versions, but were increased to 32. I'm not sure if they have been increased further. The story goes like this: A developer walks up to my desk and triumphantly claims that "I have found a bug in SQL Server!". I ask them to explain and the answer is along the lines of "my stored procedure crashes after 32 calls deep" or "my transaction crashes after 32 levels". I then patiently explain that this is not a bug but a hard limit designed to prevent users from shooting themselves in the foot. If something is nesting more than 32 levels deep then the design needs to be revisited and fixed!

When we forked MySQL Cluster at Hopsworks to build RonDB, we wanted to make the world's fastest database easier to configure and install - a managed service in the cloud and on Kubernetes. We did that. We also added capabilities for real-time AI workloads. That work is never finished. But, we are also moving towards serverless infrastructure. Rate limits and quotas are key to building multi-tenant services, and that's why it's exciting they are coming to RonDB.

Solid Cache A new disk-backed ActiveRecord::Cache::Store. Bigger, cheaper, faster. https://lnkd.in/gjHmwfPu

eks-node-viewer is a nifty tool, showing the compute nodes currently in use in the #EKS cluster. especially useful when dynamically allocating nodes with #karpenter or auto scaling groups. https://lnkd.in/d_S9EGHv

Learn key technology differences between #Aerospike and #Redis Enterprise in our database comparison. 👇 https://lnkd.in/gGEx5Bkw #RedisReplaced

If you’re seeing increased activity in your application the last thing you want to do is worry about your database not having enough capacity to manage. Worse still is if upgrading your system to handle the load causes downtime, right when you don’t want it. This post goes into the technical details of how Neon autoscales databases to increase AND decrease CPU automatically for you. https://lnkd.in/g5Y9FF8K

A recent article update has been revised to make it clear that we did not suggest, imply, or recommend that SMT should be disabled on bare-metal systems with more than 64 logical cores per NUMA node, to get around a fixed limit in SQL Server. We suggested that customers consider reducing the logical core count per NUMA node, using sub-NUMA clustering (SNC) or Nodes Per Socket (NPS) options for bare-metal systems, depending on their CPU vendor. The confusion likely arose from our advice for VMs (in the same section of the article), which is to disable SMT if the core count presented to the operating system exceeds 64 logical cores per NUMA node. Hopefully this clarifies the issue. https://lnkd.in/gVSBC4hz