Rowhammer Bug:攻擊記憶體的值...

GoogleProject Zero 實做 Rowhammer Bug:「Exploiting the DRAM rowhammer bug to gain kernel privileges」。

開頭就很科幻:

“Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows.

然後就提到實做了:

We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect.

給出了 NaCl sandbox escape 與 Kernel privilege escalation 兩種方式。

這頭快炸了...

Ruby 2.2.0:放假前的新版本

Ruby 2.2.0 在假期前釋出:「Ruby 2.2.0 Released」。

在「Notable Changes since 2.1」的部份有提到新的 GC algorithm (Incremental GC) 以及讓 Symbol 可以被 GC (Symbol GC),而且提到了 Rails 5.0 會受益於此:

Recent developments mentioned on the Rails blog suggest that Rails 5.0 will take advantage of Incremental GC as well as Symbol GC.

在 Rails 這邊的說明:

Rails 5.0 will target Ruby 2.2+ exclusively. There are a bunch of optimizations coming in Ruby 2.2 that are going to be very nice, but most importantly for Rails, symbols are going to be garbage collected.

單台 12TB RAM 的 server

翻資料的時候翻到「Scalability Techniques for Practical Synchronization Primitives」這篇文章,裡面剛好提到 HP 的高階伺服器:

HP 的 CS900 (HP ConvergedSystem) 看起來是搭著 SAP HANA 而出的硬體...


出自「http://ascii.jp/elem/000/000/946/946459/img.html

記錄起來,如果有需要用到的時候可以去問問 HP...

Valgrind 的其他用途

這篇文章的標題就說明了作者對 Valgrind 只被拿來抓 leak 很不滿:「Valgrind is *NOT* a leak checker」。

依照文章裡的說法:

Valgrind is an undefined behavior checking tool first, a function and memory profiler second, a data-race detection tool third, and a leak checking tool last.

文章裡從最簡單的用法 (什麼參數都不加) 開始解釋,到後面的 leak 檢查以及 profiling,算是還蠻清楚的 XDDD

HDFS 上的 Memory Storage

Apache Spark 以記憶體操作為賣點的想法,有人提出來直接讓 HDFS 支援 Memory Storage 了:「Discardable Distributed Memory: Supporting Memory Storage in HDFS」,文章的副標題「HDFS's storage subsystem gets a boost with discardable distributed memory」也說明了特性。

整個計畫在「[HDFS-5851] Support memory as a storage medium - ASF JIRA」這邊可以看到。

不過 Spark 帶來的想法現在才有進度... 這發展的速度也太快了 XD

Percona Server 5.5.30-30.2 (based on MySQL 5.5.30) 的改善

Percona 在前幾天推出基於 MySQL 5.5.30 的 Percona Server 5.5.30-30.2:「Percona Server for MySQL 5.5.30-30.2 now available」。

5.5.30-30.2 這個版本引入了 jemalloc

Percona Server for MySQL will now be shipped with the libjemalloc library. Benchmark showing the impact of memory allocators on MySQL performance can be found in this blogpost. (Ignacio Nin)

在去年 (2012 年) 七月 Percona 就有分析過 glibc 與 jemalloc 對效能的差異:「Impact of memory allocators on MySQL performance」,可以看到在 concurrent active connection 數量愈高,jemalloc 的優勢愈明顯。

預設總算把 jemalloc 包進去了,等好久了...

另外一個是「trx descriptors: MySQL performance improvements in Percona Server 5.5.30-30.2」,針對 transaction lock 問題的改善。

這邊比較時都用 jemalloc,是因為 Percona Server 5.5.30-30.2 是用 jemalloc,比較時必須盡可能維持一樣的條件。

圖表可以看到 Percona 把 5.6 的改善方式再改善,然後 backport 回 5.5,使得沒有被飆為 read only transaction 的 query 也能受益。

AWS 歷史上第一台 RAM 比儲存空間多的 instance...

看到 AWS 推出新的 EC2 instance:「EC2 for In-Memory Computing - The High Memory Cluster Eight Extra Large Instance」,看完這個 instance 的規格笑了出來 XDDD

120GB SSD 兩顆 (所以是 240GB),加上 244GB RAM,結果記憶體比 SSD 空間大,應用程式一定得分層利用... XDDD

Colin Percival 開了台 FreeBSD 9.1 起來測試,可以順便看到一些硬體資訊。

目前還沒有 Reserved Instances 可以買,所以依照目前的價錢 USD$3.50/hour,一年大約是 90 萬新台幣,而這金額差不多可以直接買一台了... 所以這個 instance 的定位是在非長期的大量運算?不過依照 AWS 的慣例,過陣子應該還是會出 Reserved Instances 讓需要的人買...

不過這也是目前記憶體最多的機器,如果下次看到有文章寫「因為資料超過 244GB,所以資料庫效能炸掉」的訊息,就知道發生什麼事情了 XDDD

Firefox 省記憶體的套件:AFOM

Firefox 上回收記憶體的套件,目前只有 Windows 平台有支援:「AFOM - Memory Recovery & Retention For Firefox Only」,用了幾個禮拜後發現效果還蠻不錯,也還算穩定... 桌機只有 2GB RAM,還沒打算要升級,先頂著用...

效果的部份可以參考「AFOM 有效解決 Firefox 記憶體咬住不放的擴充套件」這篇裡的資料。

Perl 的 Object::Destroyer

使用 HTML::Tree 時因為有 circular reference,會要求你要使用 ->delete() 告知 object 打斷 reference 以避免 memory leak。於是就得很小心寫,要注意每個步驟以免某些狀況下忘記 ->delete() 而造成 leak:

my $html = HTML::TreeBuilder->new_from_content($body);
foreach my $element ($html->look_down('a', qr{某個 RE 條件})) {
    if (符合某個條件) {
        # 做某些事情...

        $element->delete;
        $html->delete;
        return;
    }

    # 做某些事情...
    $element->delete;
}
$html->delete;

後來找到了 Object::Destroyer,利用另外一個 object 的存活幫忙回收,於是就可以簡化成:

my $html = HTML::TreeBuilder->new_from_content($body);
my $htmlD = Object::Destroyer->new($html, 'delete');
foreach my $element ($html->look_down('a', qr{某個 RE 條件})) {
    my $elementD = Object::Destroyer->new($element, 'delete');
    if (符合某個條件) {
        return;
    }
    # 做某些事情...
}

這樣就不會 leak 了...