Tag: ram

Alpaca.cpp 有 13B 與 30B 的 model 可以玩了

在「Stanford Alpaca 與 Alpaca.cpp」這邊有提到 Alpaca 有放出 7B 的 model 可以用，後來 community 也照著同樣的方式訓練出對應的 13B 與 30B 的 model 了，在 Alpaca.cpp 專案的 README.md 有寫怎麼取得。

看起來比較大的限制是記憶體，13B 與 30B 的記憶體建議是 >10GB RAM 與 >32GB RAM，不知道剛好 32GB RAM 跑不跑得動，先拿 32GB RAM 的機器跑看看，如果真的不行的話家裡桌機是 64GB RAM，應該是不會有大問題...

不過 13B 的 model 檔案位置是放在 IPFS 上，透過這幾個 gateway 下載起來都有點慢，有需要的人用 BitTorrent 可能會快一點？

Update：測了一下 13B 的版本：

> Explain FAANG.
FAANG refers to five of America's largest technology companies - Facebook, Apple Inc., Amazon, Netflix and Google (Alphabet). These are some of the most valuable brands in today’s marketplace with a combined value that exceeded $3 trillion as at 2018.

以及 30B 的版本：

> Explain FAANG.
FAANG stands for Facebook, Amazon, Apple, Netflix and Google - five of the most powerful technology companies in today's world. These tech giants have become increasingly influential over recent years due to their dominance in various markets such as social media platforms (Facebook), e-commerce websites (Amazon) or streaming services (Netflix).

Windows 11 瘦身版本的 Tiny11

Tiny11 是 NTDEV 弄出來的精簡版 Windows 11：「De-Bloated Windows 11 Build Runs on 2GB of RAM」。HN 上對應的討論在「De-Bloated Windows 11 Build Runs on 2GB of RAM (tomshardware.com)」。

It just uses around 8GB of space compared to the 20+GB that a standard installation does.

但有些限制，像是安全性更新需要自己來：

This OS install “is not serviceable,” notes NTDev. “.NET, drivers and security definition updates can still be installed from Windows Update,” so this isn’t an install which you can set and forget.

另外像是透過 WinSxS 安裝的功能 (包括語言) 會無法安裝：

Moreover, removing the Windows Component Store (WinSxS), which is responsible for a fair degree of Tiny11’s compactness, means that installing new features or languages isn’t possible.

但我記得拔掉 WinSxS 應該會影響蠻多東西的？這樣的系統應該是拿來跑跑 CI 或是固定用途還行，一般性的用途不知道會卡多少東西...

另外除了使用的磁碟空間變小以外，記憶體的使用量也大幅下降，畢竟也拔掉了一堆肥大的軟體：

In testing, NTDev said that Tiny11 could “run great” on a system with just 2GB of RAM.

AWS 東京區有 12TB 記憶體的機器了

月初 AWS 宣佈東京區有 u-12tb1.112xlarge 可以用了：「Amazon EC2 High Memory instances with 3, 6, 9, and 12TiB of memory are now available in Asia Pacific (Tokyo) region」。查了一下 on-demend 的價錢是 $131.733/hr，如果一個月以 720 小時來算，要 $94847.76/mo...

沒記錯的話，這種機器應該是要另外申請 limit 才能開，沒辦法說測就測。另外在公告裡面有提到 savings plan ，但沒提到 RI (reserved instance)，不確定是不是還沒開 RI 讓使用者買 (不過我記得 savings plan 好像也有類似的折扣結構)：

Starting today, Amazon EC2 High Memory instances with 3TiB (u-3tb1.56xlarge), 6TiB (u-6tb1.56xlarge, u-6tb1.112xlarge), 9TiB (u-9tb1.112xlarge), and 12TiB of memory (u-12tb1.112xlarge) are available in Asia Pacific (Tokyo) region. Customers can start using these new High Memory instances with On Demand and Savings Plan purchase options.

這種機器是用暴力解決問題的機器...

Ribbon filter

在 RocksDB 的 blog 上看到「Ribbon Filter」這個，主要是 RocksDB 從 6.15 開始支援 Ribbon filter，取代本來的 Bloom filter 機制。

RocksDB 的 wiki 上面是說用 CPU 資源換 memory 的使用量：

A new Bloom filter alternative is available as a drop-in replacement (since version 6.15.0), saving about 30% of Bloom filter space (most importantly, memory) but using about 3-4x as much CPU on filters. Most of the additional CPU time is in the background jobs constructing the filters, and this is usually a good trade because it is common for SST filters to use ~10% of system RAM and well under 1% of CPU.

論文則是在「Ribbon filter: practically smaller than Bloom and Xor」這邊可以看到，Facebook 之前也有提到 Ribbon filter：「Ribbon filter: Practically smaller than Bloom and Xor」，在 Hacker News 上有對應的討論可以翻：「Ribbon filter: Practically smaller than Bloom and Xor (fb.com)」。

在 Ribbon filter 的資料裡面都提到了 Xor filter 當作比較，先前在「比 Bloom filter 與 Cuckoo filter 再更進一步的 Xor filter」這邊有提到 Xor filter。

用 CPU 去換記憶體，算是特化的版本...

EC2 的大記憶體機器又推新規格了...

這次 Amazon EC2 的機器又推出一些新規格了：「Amazon EC2 High Memory Instances now available for on-demand usage」。

然後每次推這些機器的時候都會提到 SAP HANA，都沒有其他的例子可以說... 話說業界就只剩下這套系統是完全都沒在考慮分散式架構嗎 XDDD (完全沒用過)

SAP customers continue to leverage AWS as their platform of choice and innovation. Some are in the early stages of their SAP cloud journeys and are focused on executing their migration. Others have hardened their SAP systems on AWS and are innovating around their core business processes with advanced AWS services.

另外他有提到 24TB 的機器，在 Amazon EC2 Instance Types 這邊可以翻到 u-24tb1.metal：

In 2018, we released High Memory Instances in response, which now offer up to 24TB of memory in a single instance.

不過你會發現在 Amazon EC2 On-Demand Pricing 這邊翻不到 24TB 的價錢，先前在「EC2 推出 18TB 與 24TB 的機器...」這邊有過這些機器買三年 RI 才能用，所以這次推出來 12TB 的機器算是隨時租用的機器裡面記憶體最多的了...

u-12tb1.112xlarge 在 us-east-1 的價錢是 USD$109.2/hour，想要玩的人可以測試看看，至少應該玩的動 XD

AWS 推出 X2gd 機種，針對記憶體再提供更便宜的方案

AWS 推出了 X2gd 機種，用 ARM 的 CPU，然後給更少顆，disk 也更小，但換來的就是價錢更低：「New Amazon EC2 X2gd Instances – Graviton2 Power for Memory-Intensive Workloads」。

把兩個用 ARM 的主機拿出來看看 us-east-1 的價錢，第一個是這次的 x2gd.medium，只有 1 vCPU + 59 GB SSD，但有 16 GB RAM，現在的價錢是 $0.0835/hr。

另外一個 r6g.large 則是 2 vCPU + 16 GB RAM，然後 EBS only，則是 $0.1008/hr。

再來是 Intel 的 x1e.xlarge，這邊是 4 vCPU + 12 GB RAM + 120 GB SSD，單價也差不多，不過記憶體少了點，$0.834/hr。

另外 Intel 也有 r5.large，2 vCPU + 16 GB RAM + EBS only，$0.126/hr。

最後一個是 AMD 的 r5a.large，跟 Intel 的 r5.large 也很像，2 vCPU + 16 GB RAM + EBS only，$0.113/hr。

這次推出的 X2gd 機種提供了只要記憶體的極端選擇，而且依照先前的經驗，Graviton2 真的很快，1 vCPU 未必會不夠用... 至少我 blog 的 PHP 與 MariaDB 都是跑在 t4g 上面，看起來比之前放在 VPS 上快不少 :o

把 blog 從 t4g.small 降到 t4g.micro

我在「把 blog 搬到 t4g.small 上」這邊有提到把這個 blog 搬到 Amazon EC2 的 t4g.small 上 (2GB RAM + 20% CPU credit)，跑了一陣子把 CPU usage 拉出來看：

當初估大約要 20% 的 CPU credit，結果發現 CPU credit 大概用 5% 就夠了。另外記憶體的部份大約要給 1GB，這個量可以看出來一些沒在用的 process 會被丟到 swap：

              total        used        free      shared  buff/cache   available
Mem:          952Mi       380Mi        79Mi       110Mi       492Mi       368Mi
Swap:         511Mi       152Mi       359Mi

把條件綜合起來計算，就往下降一階變成 t4g.micro 了 (1GB RAM + 10% CPU credit)。

另外新機種比較不用擔心淘汰速度，就看了一下 Reserved Instances 的價錢，一年 USD$44，三年 USD$84，看起來只要有用兩年就算是 OK，直接買三年解決掉...

Percona 對 MongoDB 的建議

看到「5 Things DBAs Should Know Before Deploying MongoDB」這篇，裡面給了五個建議，其中第五點頗有趣：

5) Whenever Possible, Working Set < RAM

As with any database, fitting your data into RAM will allow for faster reads than from disk. MongoDB is no different. Knowing how much data MongoDB has to read in for your queries can help you determine how much RAM you should allocate to your database.

這樣的設計邏輯很奇怪啊，你不要扯其他 database 啊，你們家主力的 InnoDB 一直都沒有推薦要 Working Set < RAM 啊，反過來才是用 InnoDB 的常態吧，而且在 PostgreSQL 上也是這樣吧 XDDD

現在上面的文章真的是挑著看了... XD

Raspberry Pi 4 推出 8GB 版本

Raspberry Pi 宣佈了 8GB 版本：「8GB Raspberry Pi 4 on sale now at $75」。

除了記憶體變成 8GB 以外，也因為記憶體加大而需要更多電力，所以電供元件的部份也跟著改動，然後也提到 COVID-19 造成的延遲：

To supply the slightly higher peak currents required by the new memory package, James has shuffled the power supply components on the board, removing a switch-mode power supply from the right-hand side of the board next to the USB 2.0 sockets and adding a new switcher next to the USB-C power connnector. While this was a necessary change, it ended up costing us a three-month slip, as COVID-19 disrupted the supply of inductors from the Far East.

超過 4GB 的時候一定會檢視 32-bit 與 64-bit 環境的差異，所以就會發現，在預設的 kernel 因為使用 32-bit LPAE (ARM 上的 PAE)，所以雖然是有機會可以使用到 8GB，但單一程式會有 3GB 限制：

Our default operating system image uses a 32-bit LPAE kernel and a 32-bit userland. This allows multiple processes to share all 8GB of memory, subject to the restriction that no single process can use more than 3GB.

目前如果想要原生支援 64-bit 環境的話，需要使用其他作業系統：

But power users, who want to be able to map all 8GB into the address space of a single process, need a 64-bit userland. There are plenty of options already out there, including Ubuntu and Gentoo.

不過另外官方也在測自家的 64-bit 版本，已經有 early beta 版本可以測試看看了 (話說 early beta 這個詞，可以解釋成 alpha 的品質...)：

Not to be left out, today we’ve released an early beta of our own 64-bit operating system image. This contains the same set of applications and the same desktop environment that you’ll find in our regular 32-bit image, but built against the Debian arm64 port.

不過上面的 Chromium 與 Firefox 不完整支援硬體解壓影片的部份還是痛，四代的 CPU 在 YouTube 上是可以硬撐 1080p30 解碼，但畫面順暢度就不太行了，客廳還是用老 Mac Mini (2011 的版本) 來撐場...

OpenVZ 裡的 Docker

前幾天在公司弄 GitLab 與 GitLab CI，前者光跑起來都還沒動他就先吃 1.5GB 左右的記憶體，動兩下就 2.5GB 了。後者的 CI 隨著使用的情況而改變，不過最少丟個 1GB 差不多...

公司用的機器當然是還好，先簡單弄一台 t3a.medium (4GB) 跑 GitLab 主體，然後另外一台 t3a.small (2GB) 跑 CI 的 Runner，真的有需要的時候可以再往上拉...

不過自己也要弄的時候就會考慮到成本問題，畢竟也只有自己一個人用，如果在 Vultr 上面租類似的機器就要 USD$30/month，其他的 KVM VPS 也都差不多價錢。

而 OpenVZ 的 VPS 主機一向都比 KVM 的 VPS 便宜不少，但有不少限制。其中一個限制就是沒辦法跑 Docker，這樣就沒辦法把 GitLab CI 的 Runner 跑上去了 (有其他模式可以跑，但我這邊偏好用 Docker)。

查了一下資料 (因為記得 OpenVZ 有計畫要支援 Docker)，發現 OpenVZ 7 已經支援 Docker 了，而且在官方文件上面也都已經有說明了：「10.3. Setting Up Docker in Virtuozzo Containers」、「Docker inside CT vz7」。

然後順著找一下，發現市場上也已經有 OpenVZ 7 的 VPS，而且會宣傳支援 Docker，試著租一個月也確認可以跑，這樣代表之後又有更多選項啦...