北海道自駕行:一些心得

本文同步刊登於:北海道自駕行:一些心得 @ あなたがいるから

這次去北海道,挑戰了人生第一次右駕。過程中雖然還算平順,不過也有差點轉到對向車道的時候 (爆)
最後開了八天,里程數是 1100 公里。以下大概條列式的整理一下要在北海道開車的重點。

2014-05-13 09.01.12

1. 事前準備
因為日本不承認台灣的國際駕照,所以在出國前,要帶著台灣的駕照到監理站去申請「日文譯本」,費用是新台幣 100 元。(臺日雙方駕照互惠措施須知)。日文譯本是一張 A4 大小的紙,租車的時候租車公司除了會看譯本外,也會看中文正本,所以不要忘記帶台灣的駕照。

2. 租車
我們是在格安租車 北海道這家公司租的。他是一家旅行社,會幫你跟租車公司聯絡租車事宜,線上刷卡付款後,會寄預約結果過來,列印出來後帶到現場就好。如果會開高速公路,要租 ETC 卡的話(日本的 ETC 跟遠通第一版 ETC 一樣,是機器跟卡分開),也可以寫在備註中請他聯絡租車公司。如果需要甲地租乙地還,通常需要多加一點錢。與大眾運輸工具比起來,三個人共乘一台車,費用差不多可以打平大眾交通工具的費用。

3. ETC
如果要開高速公路的話,強烈建議一定要租 ETC 卡。除了方便之外,在離峰時段還有打折,而且還可以還車的時候再結算。另外北海道有提供外國人 ETC 吃到飽的方案(Hokkaido Expressway Pass, HEP),如果會常常上高速公路的話,也是一個好選項。但是,如果要使用 HEP 的話,租車的全程都必須付費。也就是說,不能因為第三天開始才會上高速公路,指定讓 HEP 的效期從第三天開始。

4. GPS
日本的 GPS 非常方便,前提是一定要先查到景點的「電話」或是「Map Code」。有時景點的電話會是管理機構的電話,這時可以試著查附近景點,再按照指標過去。

5. 加油
一定要先摸消除靜電的裝置!很重要!北海道非常乾燥,只是開個車門每次都被電到,更不要說加油了。
加油有分「セルフ」(自助)、「セミセルフ」(人工加油但是沒有清潔服務)、「スタッフ」(人工加油,含車輛外觀基本清潔),基本上都是加便宜的セルフ和セミセルフ啦。另外油也有分等級,一般的車都是加レギュラー的油,除非租到柴油車。
加油的時候,用現金會比較便宜,先選擇油種,投錢後才開始加油。還車前,要加滿油,店員會檢查油表與加油的收據。另外,上高速公路前,請先確定油是夠的,因為可能有 100 公里以上的路段沒有加油站…

DSC02942
這次租的車有油耗顯示(每公升的油可以開多少公里),超過 20 公里的話會亮 ECO 的燈。如果一路上都能保持超過 20 公里的話,超有成就感的。

6. 高速公路
通常高速公路的速限是 100,但是有很大部分(道南、道東)只有 70。當地人開車都超猛,在 70 的路段開 100 還是追不上前車的車尾燈,而且還會被警察攔下來。遇到的時候,一定要減速停在路邊,配合警察的檢查。聽旅館的服務生說,警察會特別攔租車車牌的車(わ開頭的),不知是真是假。總之,保持速限,就算當路隊長(還蠻常當的,當地人開車真的猛,有時速限 100 開 105 也還是會當路隊長…)也不要害怕,當有超車道的時候其他車會自己超過去。另外,有雙線道的時候,內側車道是超車道,如果不是要超車,絕對不要在上面行駛。

7. 停車
會租車的話,一定是因為想去大眾運輸工具不方便到的地方(例如一天只有一班火車之類的地方),通常這些地方都有停車場,一次 300 日元或 500 日元。市區的話停車非常貴,在札幌市中心,有一小時 600 日元的停車場。如果要在市中心晃,把車停在旅館再搭電車或者走路過去會比較方便。旅館一天的停車費大概是 1000 ~ 1500 日元之間,有些需要事前預約,要注意一下。

在北海道開車比在台灣輕鬆多了,如果行程中有安排比較不「大眾」的景點的話,也許可以考慮租一兩天車去玩也不錯 :)

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Google Cloud Platform 在台灣設點

新聞稿:Google Cloud Platform expands to Asia Pacific

比較不舒服的是 Google Compute Engine (Google 的虛擬主機) 必須要裝 Google 提供的 SDK 才能連進去,門檻比較高。在 Windows 系統下需要安裝 cygwin 與 python 才能使用。

連進去之後速度還不錯,畢竟在島內還是有差。

                                                                   My traceroute  [v0.85]
aqua (0.0.0.0)                                                                                                                     Tue Apr 15 22:43:50 2014
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                                                   Packets               Pings
 Host                                                                                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.1.1.251                                                                                                    0.0%    37    0.2   0.2   0.1   0.5   0.0
 2. 60-199-247-252.static.pixnet.tw                                                                               0.0%    37    0.4   3.3   0.3  36.4   7.6
 3. 60-199-236-149.static.tfn.net.tw                                                                              0.0%    37    0.9   0.6   0.4   3.9   0.6
 4. 60-199-255-4.static.tfn.net.tw                                                                                0.0%    37    0.5   1.8   0.4  45.5   7.4
 5. 60-199-20-161.static.tfn.net.tw                                                                               0.0%    37    0.6   1.8   0.4  47.2   7.7
 6. 60-199-3-190.static.tfn.net.tw                                                                                0.0%    37    1.0   2.0   1.0  27.2   4.4
 7. 60-199-23-42.static.tfn.net.tw                                                                                0.0%    37    1.6   3.4   1.1  14.5   3.7
 8. 72.14.212.145                                                                                                 0.0%    37    1.2   5.9   1.2  44.6   8.8
 9. 209.85.243.26                                                                                                 0.0%    37    1.9   3.0   1.3  29.2   5.1
10. 209.85.250.101                                                                                                0.0%    37    3.0   3.1   2.8   5.8   0.7
11. ???
12. 172.178.167.107.bc.googleusercontent.com                                                                      0.0%    36    6.6   6.7   6.6   7.4   0.0

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Mac OS X 外接螢幕顯示模糊問題

最近把 Macbook 送修,改用 Mac Mini 外接 Dell U2412 來工作,結果一接上螢幕發現顯示非常模糊,品質比用類比 VGA 接頭還慘。
後來查了一下,才知道不只 Mac Mini,新的 Mac OS X 只要外接螢幕,都有人遇到同樣的問題,並且也有解決的方法:Dell U2713H on Mac: forcing RGB mode instead of YCbCr。修正的步驟如下:

  1. 下載 https://gist.github.com/adaugherity/7435890
  2. 連接外接螢幕,並且把內建的螢幕關閉(蓋上 Macbook 上蓋)
  3. 執行 patch-edid.rb:ruby patch-edid.rb
  4. 將上一個步驟產生的目錄搬到 /System/Library/Displays/Overrides
  5. 重開機,螢幕顯示就會恢復正常了
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

MySQL 的 Thread Pool (Percona 版本) 實測

MySQL Thread Pool 的介紹可以參考 Percona 的文章:,以及 DK 的介紹:MySQL 上的 Thread Pool…

一言以蔽之:資源使用量有減少,但看不出明顯的效能改善,可能是負載還不夠大。

MySQL Thread 數量(開啟 Thread Pool 前):

MySQL Thread 數量(開啟 Thread Pool 後):

System Thread 數量(開啟 Thread Pool 前):

System Thread 數量(開啟 Thread Pool 後):

可以看到在同樣約 2000 個 MySQL Thread 的情況下,開啟 Thread Pool 的 System Thread 數量只有約 200 個;開啟前約需要 3000 個 Thread。兩張圖是使用配備完全相同的兩台機器測試的。

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

使用 pt-stalk 找出 MySQL 效能問題

pt-stalkPercona Toolkit for MySQL 裡面的其中一項工具。它會連到 MySQL Server,監控指定的數值,當超過指定的 Threshold 時,收集當時資料庫執行的資訊(包含正在進行的 transaction、vmstat、lsof,甚至 gdb stack trace),方便分析解決問題。

pt-stalk 需要以 root 權限執行。執行的方法如下:

pt-stalk --daemonize --variable Threads_connected --threshold 400 -- --defaults-file=/etc/mysql/my.cnf

當同時有 400 以上的 Threads 時,便會收集資料,存到 /var/lib/pt-stalk 內。收集的資料範例:

2014_01_13_00_25_09-df              2014_01_13_00_25_09-lock-waits      2014_01_13_00_25_09-netstat         2014_01_13_00_25_09-ps
2014_01_13_00_25_09-disk-space      2014_01_13_00_25_09-log_error       2014_01_13_00_25_09-netstat_s       2014_01_13_00_25_09-slabinfo
2014_01_13_00_25_09-diskstats       2014_01_13_00_25_09-lsof            2014_01_13_00_25_09-opentables1     2014_01_13_00_25_09-sysctl
2014_01_13_00_25_09-hostname        2014_01_13_00_25_09-meminfo         2014_01_13_00_25_09-opentables2     2014_01_13_00_25_09-top
2014_01_13_00_25_09-innodbstatus1   2014_01_13_00_25_09-mpstat          2014_01_13_00_25_09-output          2014_01_13_00_25_09-transactions
2014_01_13_00_25_09-innodbstatus2   2014_01_13_00_25_09-mpstat-overall  2014_01_13_00_25_09-pmap            2014_01_13_00_25_09-trigger
2014_01_13_00_25_09-interrupts      2014_01_13_00_25_09-mutex-status1   2014_01_13_00_25_09-processlist     2014_01_13_00_25_09-variables
2014_01_13_00_25_09-iostat          2014_01_13_00_25_09-mutex-status2   2014_01_13_00_25_09-procstat        2014_01_13_00_25_09-vmstat
2014_01_13_00_25_09-iostat-overall  2014_01_13_00_25_09-mysqladmin      2014_01_13_00_25_09-procvmstat      2014_01_13_00_25_09-vmstat-overall

然後看 InnoDB status,可以看到很多 transaction 正在等 query cache lock:

MySQL thread id 688253701, OS thread handle 0x7f6a591c9700, query id
19004545452 10.1.1.94 pixblog Waiting for query cache lock
SELECT * FROM `blogarticle` WHERE (`blogarticle_blogid` = 3835626) AND
(`blogarticle_date` < 1388605724) AND (`blogarticle_status` IN (2,3,5,7))
ORDER BY `blogarticle_date` desc, `blogarticle_id` desc LIMIT 1
---TRANSACTION 144B7B32FC, not started
MySQL thread id 688253702, OS thread handle 0x7f6a787bc700, query id
19004544621 10.1.1.191 pixblog Waiting for query cache lock
SELECT * FROM `blog` WHERE `blog_id` = 3126963
---TRANSACTION 144B7B32FD, not started
MySQL thread id 688253706, OS thread handle 0x7f6a887e2700, query id
19004544620 10.1.1.166 pixblog Waiting for query cache lock
SELECT * FROM `bloglayout` WHERE `bloglayout_id` = 3063007
---TRANSACTION 144B7B33C7, not started starting index read
mysql tables in use 1, locked 0

發生問題的當時確實有一個跑統計報表的 Slow Query 正在執行,於是要求該 Query 不使用 Query Cache1 來解決問題。

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Galera 3.x 的 Replication Relaying

Galera 3.x 為了多機房間的 Replication,設計了 gmcast.segment 這個參數。前陣子 Percona 的人出來介紹了這個參數背後的機制:Automatic replication relaying in Galera 3.x (available with PXC 5.6)。大致摘錄如下:

  1. 同一個機房內資料庫的 gmcast.segment 參數要設為相同。
  2. 機房與機房之間的 Replication 會自動找一個 node 進行 Relay,以降低 Replication 需要的頻寬。

    Image from: Automatic replication relaying in Galera 3.x (available with PXC 5.6)

如果沒有設定 gmcast.segment 參數的話,同樣是三個 Node,會耗用兩倍的頻寬:

Image from: Automatic replication relaying in Galera 3.x (available with PXC 5.6)

原文中另外有對作了 segment 與不作 segment 的 commit latency 進行比較,結果作了 segment 的 commit latency 並沒有比較高。如果有跨機房需求,應該要設定 gmcast.segment。

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

MySQL 5.6 的 Index Condition Pushdown

MySQL 5.6 以前的 Multi-column Index,當位於 index 中間的 column(如下例的 j)需要進行 range query 的時候,只能利用到部分的 index,需要另外讀取資料列的內容來進行判斷。舉例來說,如果有一個 Table 結構是這樣:

CREATE TABLE mytable (
id int not null auto_increment primary key,
i int(11) NOT NULL,
j int(11) NOT NULL,
k int(11) NOT NULL,
val char(10) NOT NULL,
KEY ijk (i,j,k)
) ENGINE=InnoDB;

在 MySQL 5.6 之前,SQL Query 「SELECT sum(length(val)) FROM T WHERE i=1 AND j<100 AND k=100」 會把所有 i=1 的資料列拉出來,逐一比較 j 與 k 的值。MySQL 5.6 的 Index Condition Pushdown (ICP) 功能,把這個動作改為比較 Index tuple 而非資料列內容,可避免拉出整個資料列,降低磁碟 IO(因為資料列通常比 Index 大)。

詳細的說明可以看 MySQL 的官方文件:Index Condition Pushdown Optimization 與 Percona 的測試:Multiple column index vs multiple indexes with MySQL 5.6

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Gmail 預設顯示 Email 內的圖片

上週的新聞,Gmail 會將 Email 內嵌的圖片,透過 Proxy 處理之後顯示出來。除了改進使用者體驗外,也可以避免惡意圖片攻擊使用者的電腦。

ThreatPost 上有人測試了這個功能,發現 Gmail 會在使用者開啟信件的時候,才會去抓取圖片並且進行處理,所以目前使用的開信追蹤技術,只要指定獨一無二的追蹤網址給每個用戶,還是可以正常運作。不確定 Google 是否有打算處理隱私問題?另外這篇文章也提到有可能可以利用 Google 的 Image Proxy 來作 DDoS…

也是一個值得繼續觀察的項目 XD

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone