Home » Posts tagged "server" (Page 9)

Stack Overflow 的現況...

Update:2016 年的架構可以在「Stack Overflow 公開 2016 的架構」這邊看到。

Stack OverflowNick Craver 貼出目前 Stack Overflow 的現況:「What it takes to run Stack Overflow」。

公開出來的資料不包括 CDN 的部份,可以看出整個架構很精簡啊... 然後還貼出機房照片:

可以看出很多機器都很大台,尤其是 RAM 的部份。而資料庫主機則是 384GB RAM + 1.8TB SSD...

資料庫的讀寫比是 40% read + 60% write,應該是 cache 擋下非常大的讀取量?

然後有一句粗體字:

The cost of inefficient code can be higher than you think.

這句話... XD

Percona Server 第一個 5.6 上 GA 版本...

UpdatePercona 自己也寫了一篇「A closer look at Percona Server 5.6」可以參考看看。

Percona 推出 Percona Server 5.6.13-61.0,是 5.6 的第一個 GA 版本:「Percona Server 5.6.13-61.0 first GA release is now available」。

這等好久了,MySQL 官方有給出「What's New in MySQL 5.6」,對我來說其中有幾個亮點需要測試:

效能

至少不能比現在的效能差。

對 memcache protocol 的支援

這是 5.6 的新功能,可以透過 memcache protocol 存取 InnoDB 的資料。如果可行,可以用在 HA memcache protocol 架構。

Time-Delayed Replication

看起來應該很有用,但一時間想不到可以用在哪裡... 應該是 vm 裡面多架幾台 slave 丟著?

Percona 版的修正

Twitter branch 的 Statement Timeout 看起來是個頗有趣的項目?可以想看看用在哪裡...

Overall...

總結來說,測試機測過後,先用在 DBRD + Heartbeat 的系統上 (只換一台,如果發現 5.6 版不好用,可以 downgrade),如果沒問題就再測試 memcache protocol,然後接下來就是等 Percona XtraDB Cluster 也出 5.6 版?

用 Percona Xtrabackup 產生 Slave Server 的方式...

快四年前寫過「XtraBackup:線上備份 InnoDB 的好東西」這篇,但裡面的方法已經不能用了,所以再寫一篇給 Google,之後查資料比較方便...

現在可以參考 Percona 的官方文件「How to setup a slave for replication in 6 simple steps with Xtrabackup」。

先跑一次 full backup:

innobackupex --user=yourDBuser --password=MaGiCiGaM --slave-info /path/to/backupdir

再跑 apply log:(其中的變數自己換掉)

innobackupex --apply-log --use-memory=2G /path/to/backupdir/$TIMESTAMP/

然後整個目錄丟到 slave server 上,用 CHANGE MASTER TO 指令把 master 資訊設好即可 :p

Percona 的 MySQL 5.6...

剛剛看到 Percona 放出第三個基於 MySQL 5.6 的版本了,仍然是 alpha 等級 (還在測試階段):「Announcing Percona Server for MySQL 5.6.10-60.2」。

這也是 MySQL 5.6 進入 GA 後 Percona 推出的第一個版本,而且剛剛看 Percona 的文件網站也發現建出來了:「Percona Server 5.6 - Documentation」。

Percona XtraDB Cluster 目前還是基於 5.5 的版本,不知道 Codership (Galera Cluster 的開發公司) 有沒有打算換新...

ARM Server 與 Intel Server 的比較...

在「ARM Based Server Cluster Benchmarked」看到有人對 ARMIntel 的 x86 (x86_64) 架構比較。原文在「Calxeda's ARM server tested」,ARM 的部份是以 Calxedas 的 server 測試。

重點其實在第 13 頁:

So on the one hand, no, the current Calxeda servers are no Intel Xeon killers (yet). However, we feel that the Calxeda's ECX-1000 server node is revolutionary technology. When we ran 16 VMs (instead of 24), the dual low power Xeon was capable of achieving the same performance per VM as the Calxeda server nodes. That this 24 node system could offer 50% more throughput at 10% lower power than one of the best Xeon machines available was honestly surprising to us.

雖然知道 ARM 的單位能量所產生的效能比較好,但比我想像中少... 我以為同樣電力會到兩倍。如果只有 50%+ 的話,也難怪各家都還在評估,而非大力換掉 :o

維基百科機房搬遷 (從佛羅里達州搬到維吉尼亞州)

Wikimedia 的官方網誌上看到 Wikimedia 的主機房將從 Tampa, Florida 搬遷到 Ashburn, Virginia (當然,這包括 Wikipedia):「Wikimedia sites to move to primary data center in Ashburn, Virginia」。

當初機房在 Florida 的原因是... Jimmy Wales 住附近 XDDD

A major reason for choosing Tampa, Florida as the location of the primary data center in 2004 was its proximity to founder Jimmy Wales' home, at a time when he was much more involved in the technical operations of the site.

搬遷到 Virginia 除了有比較穩定的網路以外,還包括了天氣因素 (颶風比較少)。

2011 年 11 月時,bits.wikimedia.org (主要是放 CSS 與 JavaScript) 已經改用新機房服務,2012 年 2 月時成功將 read-only page 拆到 cache server 上,同年 4 月時 upload.wikimedia.org (多媒體資料,包括使用者上傳的部份) 也導到新機房。

這幾個改變讓無法 cache 而丟到後端 ApacheMySQL 的量只剩下 10%,這次打算把這 10% 的量從 Florida 搬到 Virginia。

文末也說明了目前機器數量與 PV:

The Wikimedia Foundation currently operates a total of about 885 servers, and serves about 20 billion page views a month, on a non-profit budget that relies almost entirely on donations from readers.

全世界第六大的網站,每天約六億次 PV,現在只用了 885 台 server :p

資料庫裡的浮點數:MySQL 5.1 到 MySQL 5.5 的差異...

Mozilla 最近在升級 MySQL 採「先建後拆」的步驟,發現用 pt-table-checksum 檢查時不一致:「MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation」。

後來發現,在 MySQL 5.1 (5.1.65-rel14.0-log Percona Server (GPL), 14.0, Revision 475) 的查詢結果是:(Mozilla 的範例)

mysql> select float_field from db.tbl where id=218964;
+-------------+
| float_field |
+-------------+
| 9.58084e-05 |
+-------------+
1 row in set (0.04 sec)

而在 MySQL 5.5 (5.5.28a-MariaDB-log MariaDB Server) 的查詢結果是:

MariaDB [(none)]> select float_field from db.tbl where id=218964;
+--------------+
| float_field |
+--------------+
| 0.0000958084 |
+--------------+
1 row in set (0.24 sec)

最後是讓 pt-table-checksum 把 float/double 欄位忽略掉。在 comment 有人提出來是在 MySQL 5.5.3 的時候改變的,不過作者蠻意外沒什麼人提到...

Percona 說明關於為什麼花這麼多時間修正 MySQL 5.5.28 安全問題...

Percona 的 Stewart Smith 解釋為什麼花這麼多時間才修正這個安全漏洞:「CVE-2012-4414 strikes back in MySQL 5.5.29 (and what we’re doing in Percona Server 5.5.29)

MariaDB 的人在得知問題後先建立了 MDEV-382 這個 issue,然後建立了 rpl_mdev382.test 這份測試資料,讓其他參與者可以測試手上的 MySQL 是否有問題。

Oracle 在修正問題時並沒有使用 MariaDB 這份測試資料測過 (或是測過但因為種種因素...) 就推出 MySQL 5.5.29,但 MySQL 5.5.29 用 rpl_mdev382.test 測試會失敗,而實際確認發現 Oracle 並沒有把問題解乾淨。所以本來 Percona 預定要使用官方 MySQL 5.5.29 版本為基礎推出 Percona Server 5.5.29 (可以降低 Percona 維護成本),變成將會改用 MariaDB 的 patch。

讓 Percona 的人特地寫一篇出來,看起來對 Oracle 不太爽... XD

伺服器的 BIOS 保護機制

NIST (National Institute of Standards and Technology) 是美國的政府機關 (國家標準技術研究所),訂定了非常多的標準。像是 DES 的制定 (NIST 前身,NBS - National Bureau of Standards) 與 AES 的選拔都是 NIST 的成果。

Slashdot 上看到 NIST 對於伺服器 BIOS 的保護機制提出建議:「NIST Publishes Draft Guidelines For Server BIOS Protection」,NIST 原始公告則是在「Security First: New NIST Guidelines on Securing BIOS for Servers」。都有原始 PDF 連結可以直接點。

BIOS Protection Guidelines for Servers ToC

標題是「BIOS Protection Guidelines for Servers」,目前還是在 draft 階段,頁數也還不太多...

Archives