# Presto そのもののパラメータ
## task.shard.max-threads
* https://groups.google.com/forum/#!msg/presto-users/7aJ68pn0_oI/mzntBKvNeL4J
 * "The default number of threads per box will be 4x the number of cores on your machine, but this is configurable with the option "task.shard.max-threads"." とのこと
* http://d.hatena.ne.jp/wyukawa/20140719/1405775230 にも同様の記述がある
 * 確かにソースコードに "private int maxShardProcessorThreads = Runtime.getRuntime().availableProcessors() * 4;" という記述がある
 * https://github.com/facebook/presto/blob/master/presto-main/src/main/java/com/facebook/presto/execution/TaskManagerConfig.java
* これ、性質的には「より性能を引き出すための設定」というよりは「性能を抑えるための設定」なのではないだろうか。特に DataNode や NodeManager と共存させようとなった場合には、これで抑えてやらないとすぐに負荷が上がり過ぎてしまいそうである。
 * このパラメータである程度抑えるか、あるいは、 cgroups で CPU Affinity を指定するか、という話だろう。というか、 CPU Affinity を設定している場合、実際、どうでもよいような気もする。
* 結局のところ、たくさんジョブを並走させたとき、このパラメータが大きければ結果としてスループットも下がるだろうと考えられる。つまり、このパラメータとマシンパワーと実行速度のバランスをよく考えろ、という話になるのだろう。
 * もう少し書くと、マシンのパワーあるいは cgroups による制限がハードリミットであり、次のこのパラメータでの絞り込みになる、という話だろうと。

## query.initial-hash-partitions
* https://groups.google.com/forum/#!searchin/presto-users/task.max-memory|sort:relevance/presto-users/Hmb7L56vY6M/qC_0fPomZPsJ
 * " Currently, Presto does distributed hash aggregations across a fixed number of nodes (configured via query.initial-hash-partitions which defaults to 8)." とある
 * これは全体のノード数に応じて増やした方がよいのだろうか。
* https://prestodb.io/docs/current/release/release-0.55.html
 * "If the value is larger than the number of machines available during query scheduling, Presto will use all available machines." とのこと。まあ、増やすに越したことはないのだろう。

## node.data-dir
* これを設定しておくと、 Presto を起動した際に、このディレクトリに以下をつくる
 * Presto のインストールディレクトリの etc への symlink
 * Presto のインストールディレクトリの plugin への symlink
 * var ディレクトリ。そのなかに log, run がある。
* 設定していない場合、これはつくらずインストールディレクトリのを利用するようだ。
* ログが書き出される場所になるので、それをわけたければ便利だろうが、 etc, plugin への symlink は本当に必要なのだろうか？

## task.max-memory
* この値が JOIN できるテーブルの大きさの閾値になるような感覚の値である。
* なお、 -Xmx < task.max-memory の場合は、単にジョブが失敗するようだ。

## query.max-history
* てっきり、 coordinator で保存するクエリの履歴の数かと思ったら、そうでもないっぽい
 * あるいは query.max-age との兼ね合いなのかもしれない。詳しくは見ていない。
 * こういうのはコード読んだほうが早そう...
 * CLI のヒストリの数でもないようだ

## query.max-concurrent-queries
* 文字通りっぽい
* これを 1 に設定し、何かクエリを走らせ、完了する前にもうひとつ実行すると、待たされる。最初のクエリが完了すると、2つめが動き出す。
* 待たされている時の state は QUEUED である。
* なおこれは、 airlift の AsyncSemaphore のパラメータとして使っており、つまり、並列数制御は Presto 側ではなくあくまで airlift に任せているようだ。

## query.max-queued-queries
* 1 以上にしないとダメっぽい。0 にするとそもそも worker が起動しない。
* この値を 1 にして、1つクエリを実行し、終わるまでにもう1つ実行しようとすると `Too many queued queries!` と言われる。

## discovery.uri
* 末尾に / （スラッシュ）がつくとダメのようだ。