Hatena::ブログ(Diary)

ablog このページをアンテナに追加 RSSフィード Twitter

2017-05-23

MacBook Pro 13インチ用にマグネット式プライバシーフィルムを購入

MacBook Pro (Retina, 13-inch, Early 2015) 用にマグネット式プライバシーフィルム*1を購入。

マグネット式で簡単に取り外しできて良い感じ。


*1:2016年 MacBook Pro 13inch Late 推奨モデル UNIQ MacGuard マグネット式プライバシーフィルム Macbook 13インチ用 MBG13PF2

2017-05-22

Amazon Redshift と PostgreSQL の VACUUM FULL の動作の違い

Amazon Redshift と PostgreSQL の VACUUM FULL の動作は似ているが少し違う。どちらも空き領域を再利用するが、Redshift は「行を再ソート」する点が違う。これはそもそも、Redshift と PostgreSQL のデータ構造が異なるためで、PostgreSQL は行指向データベースのいわゆる再編成なのに対して、Redshift は行指向でソート済データを格納していて*1、ソートされてないとスキャン効率が悪化*2するためと思われる。

Amazon Redshift の VACUUM コマンドの構文と動作は、PostgreSQL の VACUUM 操作とは大幅に異なります。たとえば、Amazon Redshift でのデフォルトのバキューム操作は VACUUM FULL です。これは、ディスク領域を再利用し、すべての行を再ソートします。 これに対して、PostgreSQLデフォルトの VACUUM 操作は、単純に領域を再利用し、再び使用できるようにするだけです。


(中略)


FULL

指定されたテーブル (または現在のデータベースのすべてのテーブル) をソートし、直前の UPDATE 操作および DELETE 操作で削除対象のマークが付けられた行によって占有されているディスク領域を再利用します。完全バキュームは、インターリーテーブルインデックスを再作成しません。 インターリーテーブルインデックスを再作成するには、VACUUM REINDEX オプションを使用します。

デフォルトで、VACUUM FULL は、少なくとも 95 パーセントがソート済みであるテーブルのソートフェーズをすべてスキップします。 VACUUM がソートフェーズをスキップできれば、DELETE ONLY を実行し、削除フェーズで残りの行の少なくとも 95 パーセントが削除対象としてマークされていない領域を再利用します。

ソートしきい値に達しておらず (たとえば 90 パーセントの行がソートされていて) VACUUM が完全ソートを実行する場合は、完全な削除オペレーションも実行され、削除された行のスペースが 100 パーセント回復されます。

一つのテーブルに対してのみデフォルトの VACUUM しきい値を変更できます。 1 つのテーブルに対するデフォルトの VACUUM しきい値を変更するには、テーブル名および TO threshold PERCENT パラメータを含めます。

VACUUM - Amazon Redshift

テーブルの作成時に、その 1 つ以上の列をソートキーとして定義することができます。データが空のテーブルに最初にロードされると、行がディスク上にソート順に格納されます。ソートキー列に関する情報がクエリプランナーに渡され、プランナはこの情報を使用して、データのソート方法を利用するプランを構築します。

ソートは、範囲が制限された述語を効率的に処理することができます。Amazon Redshift は、列データを 1 MB のディスクブロックに格納します。各ブロックの最小値と最大値がメタデータの一部として格納されます。範囲が制限された述語をクエリが使用する場合、クエリプロセッサは最小値と最大値を使用して、テーブルスキャン中に多数のブロックをすばやくスキップすることができます。

ソートキーの選択 - Amazon Redshift

(FULLの無い)通常のVACUUMは単に領域を回収し、そこを再利用可能な状態に変更します。 排他的ロックが取得されていないため、この形のコマンドは、テーブルへの通常の読み書き操作と並行して実行することができます。 VACUUM FULLは、ディスクブロック数を最小にするためのブロックを跨るタプルの移動など、テーブルを縮小させるためにもっと高度な処理を行ないます。 この場合、かなり低速になり、また、処理中のテーブルに対する排他的ロックが必要になります。

VACUUM

*1:ソートキーを指定している場合

*2:ゾーンマップでブロック読込をスキップできるケースで

2017-05-17

S3で jQuery を使って SSI 的なことをする

S3 で Server Side Include (SSI)的なことを jQuery でやってみた(Client Side Include)。


結果

f:id:yohei-a:20170517142335p:image


手順

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::<バケット名>/*"
            ]
        }
    ]

ファイル

<html> 
  <head> 
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
    <script> 
    $(function(){
      $("#includedContent").load("ssi.html"); 
    });
    </script> 
  </head> 

  <body> 
     <div id="includedContent"></div>
  </body> 
</html>
<font color="red" size="7">This is ssi content.</font>

参考

2017-05-16

気になる論文3本

sched: Interrupt Aware Scheduler

Linux のプロセススケジューラで割込み負荷の高いCPU以外にプロセス(スレッド)*1をスケジューリングするパッチらしい。

The patch avoids CPUs which might be considered interrupt-heavy when

trying to schedule threads (on the push side) in the system. Interrupt

Awareness has only been added into the fair scheduling class.

It does so by, using the following algorithm:

--------------------------------------------------------------------------

1) When the interrupt is getting processed, the start and the end times

are noted for the interrupt on a per-cpu basis.

2) On a periodic basis the interrupt load is processed for each run

queue and this is mapped in terms of percentage in a global array. The

interrupt load for a given CPU is also decayed over time, so that the

most recent interrupt load has the biggest contribution in the interrupt

load calculations. This would mean the scheduler will try to avoid CPUs

(if it can) when scheduling threads which have been recently busy with

handling hardware interrupts.

3) Any CPU which lies above the 80th percentile in terms of percentage

interrupt load is considered interrupt-heavy.

4) During idle CPU search from the scheduler perspective this

information is used to skip CPUs if better are available.

5) If none of the CPUs are better in terms of idleness and interrupt

load, then the interrupt-heavy CPU is considered to be the best

available CPU.

---------------------------------------------------------------------------

Linux-Kernel Archive: [PATCH 1/2] sched: Interrupt Aware Scheduler

*1:正確にはタスク

2017-05-13

MySQL をソースコードからビルドする

準備

sudo yum install git
sudo yum install cmake
sudo yum install gcc
sudo yum install gcc-c++
sudo yum install ncurses-devel

mysql-build のインストール

git clone git://github.com/kamipo/mysql-build.git ~/mysql-build
export PATH="$HOME/mysql-build/bin:$PATH"

MySQLビルドする

mkdir -p ~/opt/mysql
mysql-build -v 5.7.10 ~/opt/mysql/mysql-5.7.10

確認する

cd ~/opt/mysql/mysql-5.7.10
./bin/mysqld --initialize-insecure --basedir=.
./bin/mysqld_safe &
  • SQL を実行する
$ ./bin/mysql -u root -e 'SELECT @@version'
+-----------+
| @@version |
+-----------+
| 5.7.10    |
+-----------+

補足

collect2: ld terminated with signal 9 [Killed]

とエラーが出たので、

Your virtual machine does not have enough memory to perform the linking phase. Linking is typical the most memory intensive part of a build since it's where all the object code comes together and is operated on as a whole.

If you can allocate more RAM to the VM then do that. Alternatively you could increase the amount of swap space. I am not that familiar with VMs but I imagine the virtual hard drive you set-up will have a swap partition. If you can make that bigger or allocate a second swap partition that would help.

Increasing the RAM, if only for the duration of your build, is the easiest thing to do though.

gcc - Why is the linker terminating on me? when i build CLang - Stack Overflow

を参考にメモリサイズの大きいマシンでビルドすると成功した。


参考

MySQLのソースコードを入手する


補足

最新バージョン以外は以下からダウンロードできる。


参考

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

P.168-169