タグ

ブックマーク / yakst.com (19)

  • インシデント指揮官トレーニングの手引き | Yakst

    [SRE]原文 An Incident Command Training Handbook – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-06-24 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1723日前 Twitterで報告済み 編集 私が Hashicorp で担った最初の仕事のひとつは、社内向けのインシデント指揮官のトレーニング資料を作ることでした。 これは私自身がインシデントへの対処にあたりながら何年ものあいだ肌身に感じてきた、あらゆる類の考えをまとめ上げる良い機会となり、最高に面白いタスクでした。 以下は私の書いたトレーニング資料、ほぼそのままです。 あなたがインシデントレスポンスのポリシーを定義するにせよ、即興でインシデントレスポンスを行うにせよ、お役に立てたら幸いです。

  • 6万ミリ秒でできるLinuxパフォーマンス分析 | Yakst

    NetflixのシニアパフォーマンスアーキテクトであるBrendan Gregg氏による、Linuxサーバにログインして60秒でまず調べることのまとめ。 パフォーマンス問題でLinuxサーバーにログインしたとして、最初の1分で何を調べますか? Netflixには、多数のEC2 Linuxからなるクラウドがあり、そのパフォーマンスを監視したり調査したりするための数々のパフォーマンス分析ツールがあります。その中には、クラウド全体にわたる監視を行うAtlasや、オンデマンドにインスタンスの分析を行うVectorがあります。これらのツールは多くの問題を解決する手助けをしてくれますが、各インスタンスにログインし、標準的なLinuxパフォーマンスツールを実行する必要がある場合もあります。 この記事では、すぐ使えるはずの標準的Linuxツールを使いコマンドラインにおいて、最適化されたパフォーマンス調査を

  • 多分あなたにKubernetesは必要ない | Yakst

    trivago社の小規模な開発チームがコンテナオーケストレーターとしてKubernetesではなくNomadを採用することになった経緯と理由について、両プロダクトの特徴やユースケースに言及しつつ紹介されています。 [HashiCorp][Kubernetes]原文 Maybe You Don't Need Kubernetes (English) 原文著者 Matthias Endler 原文公開日 2019-03-21 翻訳依頼者 翻訳者 msh5 翻訳レビュアー doublemarket 原著者への翻訳報告 1883日前 Twitterで報告済み 1882日前 原著者承諾済み 編集 スクーターに乗った女性(イラスト画像の作成元はfreepik、NomadロゴはHashiCorp) Kubernetesはコンテナオーケストレーションの巨人です。世界中で巨大なデプロイメントを動かしています

  • MySQLがメモリー不足の時に何をするか : トラブルシューティングガイド | Yakst

    MySQLがメモリー不足で停止してしまった(OOM Killerに停止させられた)時に確認すべき項目を紹介する。特に、MySQLのバグでメモリリークが起きている可能性がある場合に手がかりを得る方法について。 [MySQL]原文 What To Do When MySQL Runs Out of Memory: Troubleshooting Guide - Percona Database Performance Blog (English) 原文著者 Alexander Rubin 原文公開日 2018-06-28 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー kakuka4430 原著者への翻訳報告 1948日前 原文へのコメントで報告済み 編集 クラッシュした時のトラブルシューティングが楽しいタスクであったためしはありませんが、クラッシュの原因をMySQLが教えてくれ

  • CPU使用率は間違っている | Yakst

    Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが

    CPU使用率は間違っている | Yakst
  • MySQLインデックスのお手入れの基本 | Yakst

    Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか?順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを

    MySQLインデックスのお手入れの基本 | Yakst
    wasai
    wasai 2016/10/04
  • 読みやすいREADMEを書く | Yakst

    いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの

    読みやすいREADMEを書く | Yakst
    wasai
    wasai 2016/06/23
  • Bashのよくある間違い | Yakst

    原文は2015年8月22日時点のものを利用しており、それ以降に追記、更新されている可能性があります。 翻訳は原作者の許可を得て公開されています。 Thanks for GreyCat! このページはBashプログラマーが陥りがちなよくあるエラーについてまとめました。以下の例は全てなんらかの欠陥があります。 クオートをいつも使い、どんな理由があっても単語分割を使わなければ、多くの落とし穴からあなた自身を守ることができます!単語分割はクオート表現をしない場合にはデフォルトでオンになっている、Bourneシェルから継承された壊れたレガシーな設計ミスです。落とし穴の大半はクオートされていない展開になんらか関連し、単語分割しその結果をグロブします。 1. for i in $(ls *.mp3) BASHプログラマーたちがループを書く際にもっとも犯しがちなよくあるミスは以下のような感じです。: f

    Bashのよくある間違い | Yakst
  • MySQL 5.6と5.7における高度なクエリチューニングのQ&A(The Percona Performance Blogより) | Yakst

    8年以上前投稿 修正ありMySQL 5.6と5.7における高度なクエリチューニングのQ&A(The Percona Performance Blogより) 出典について この記事はThe Percona Performance Blog内のAlexander Rubin氏による「Advanced Query Tuning in MySQL 5.6 and MySQL 5.7 Webinar: Q&A」(2015/8/24)を翻訳したものである。 8月22日のオンラインセミナー「MySQL 5.6および5.7における高度なクエリーチューニング」に参加していただいてありがとう(私のスライドおよび動画はここで確認できる)。ここでは質問とその回答の一覧を紹介する(いい質問をありがとう) 。 Q: ここにexplainの例がある mysql> explain extended select id,

    MySQL 5.6と5.7における高度なクエリチューニングのQ&A(The Percona Performance Blogより) | Yakst
  • MySQL 5.7におけるサーバーのデフォルト値の改善 (MySQL Server Blogより) | Yakst

    MySQL 5.7でのデフォルト値の変更について簡単に紹介する。レプリケーション、InnoDB、パフォーマンススキーマ、セキュリティー、オプティマイザ、その他全般の改善など様々な改善がされている。 免責事項 この記事はMatt Lord氏によるMySQL Server Blogの投稿「Improved Server Defaults in 5.7」(2015/7/22)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 Morganと私はしばらく前にMySQLの"今やもう良くない(out of the box)"設定および挙動のデフォルト値を改善する計画を開始した。コミュニティーと密接に実施することにより、すばらしい改善の一覧が作成できた。これはMySQL 5.7.7のリリースから成果を出し始めた。私は何が変わったか、通常のユーザーおよびインストールの場合、なぜMySQL

    MySQL 5.7におけるサーバーのデフォルト値の改善 (MySQL Server Blogより) | Yakst
    wasai
    wasai 2015/08/10
  • MySQLインデックスの基礎 その2 : 2つのクエリの違いとオプティマイザの判断 | Yakst

    MySQLのインデックスを効果的に使う方法の第2弾。よく似た2つのクエリなのに、実際にはインデックスの使い方がそれぞれ異なることを通じて、オプティマイザがどのようにクエリの実行計画を立案するのか、そしてその結果どうインデックスが使われるのかを解説する。 前の記事では、ひとつのテーブルに対する様々なクエリを対象にして、インデックスのデザイン方法について議論しました。この記事ではより実世界に即した問題解決の例として、よく似ているにも関わらず、ひとつは適したインデックスを使い、もうひとつはフルテーブルスキャンをしてしまうという、2つのクエリを取り上げます。動作の違いはバグなのでしょうか?それとも想定された動きなのでしょうか?続きを読んでみてください! 対象のクエリ2つ # Q1 mysql> explain select col1, col2 from t where ts >= '2015-0

    MySQLインデックスの基礎 その2 : 2つのクエリの違いとオプティマイザの判断 | Yakst
  • MySQLインデックスの基礎 : ひとつのテーブルに対するクエリの最適化法 | Yakst

    MySQLのインデックスを効果的に使うにはどうしたらいいのかについての分かりやすい解説。そもそもインデックスの役割はとは何か、そしてどうすればその役割を果たしてくれるのかを説明する。 たとえ1つのテーブルだけに対して実行されるクエリでも、パフォーマンスが悪いというのはよくあることです。その理由は簡単で、インデックスの作り方がまずいため、実行計画がおかしくなってしまうのです。ここでは、1つのテーブルのみに対する色々なクエリを最適化するためのガイドラインを挙げてみたいと思います。 おことわり : あらゆる状況をカバーしようとはせず、一般的なガイドラインを提示するに留めるつもりです。ここで挙げたものがうまく適用できない例を簡単に見つけることができるのは間違いないでしょうが、ほとんどの場合はここに書いたことが十分なのも事実です。また、MySQL 5.6以上にあるIndex Condition Pu

    MySQLインデックスの基礎 : ひとつのテーブルに対するクエリの最適化法 | Yakst
  • MySQLとその仲間の過去・現在・未来 - MySQLの過去を振り返る Part 1 | Yakst

    長らくMySQLの開発に関わってきたStewart Smith氏が、MySQLの誕生から現在、将来の展望までを駆け足で語る。Part 1は、MySQLの始まりとMySQL AB社の創業、デュアルライセンスの採用まで。 linux.conf.au 2014での発表内容のビデオはこのURLから見られる(訳注 : この記事は、元々原文の筆者が発表したものを書き起こしたもの)。 ここではビデオではなくブログ記事としてこの内容についてみてみよう。 1979年、UNIREGというソフトウェアがあった。データベース(いや、テーブルか)に行を保存するためのテキストUIだ。UNIREGのことを出してきたのは、それがFoRMsという仕組みを使っていて、(MyISAMのディクショナリ情報を格納する)FRMファイルがその頭文字を使っているっぽいからだ。 1986年には、UNIREGはUNIXで動くようになった。そ

  • MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst

    MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、

    MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst
  • MySQLを使ったアプリケーションを作るエンジニアが知るべきMySQLの内部構造とは? | Yakst

    MySQLを使ったアプリケーションを作るエンジニアが知るべきMySQLの内部構造について、データベースコンサルティング会社PalominoDBを経営するLaine Campbell氏による回答。MySQLを知るためには何をポイントに学習すればよいのかがよくわかる、DBAや開発者にとっても役立つ内容。 1. ストレージエンジン ストレージエンジンと、永続性、ロック機構、トランザクション処理の振る舞いや分離レベルといったストレージエンジンの基礎となる動きについての理解なしに、MySQL自体やモデルデータのコードをいじるべきでない。それに加えて、InnoDBのクラスタ化されたプライマリキーや、MyISAMの全文検索インデックスのようなコア要素も、極めて重要な情報だ。 2. インデックスのコンセプト 特に以下のような点について。 カバリングインデックス 連結インデックス インデックスを使ったソート

  • MySQL 5.7のマルチソースレプリケーション | Yakst

    MySQL Performance Blogの翻訳。MySQL 5.7開発版と合わせてアナウンスされた、マルチソースレプリケーション。マルチマスタとの違いと、マルチソース環境の概要を、実際の設定や動きを交えながら解説する。 October 2, 2013 By Miguel Angel Nieto 最近Oracleは、この記事を書いている時点でバージョン5.7.2の最新MySQL開発版に対して、数々の新機能をアナウンスした。これらの多くは、新しいリリースが非常に素晴らしいものになるであろうことを予感させるパフォーマンスやレプリケーション関係の機能だ。 この記事で、新しいマルチソースレプリケーションの機能をどう動かすかの簡単な手順と、テストのためにどう設定すべきかを説明しようと思う。これは開発版なので、すぐに番環境で使えるものではないことをあらかじめ指摘しておこう。いずれにしても、開発環境

    MySQL 5.7のマルチソースレプリケーション | Yakst
  • MySQL 5.6のインストール後にチューニングすべき項目 | Yakst

    MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -

    MySQL 5.6のインストール後にチューニングすべき項目 | Yakst
  • (帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst

    MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 当にたくさんのことが変わったものだ!この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている

    (帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
  • 私が他人のシェルスクリプトから学んだこと | Yakst

    私はシェルスクリプトの大ファンで、他人のスクリプトから面白い方法を学ぶのが大好きだ。最近、SSHサーバの2要素認証を簡単にするためのauthy-sshスクリプトに出会った。このスクリプト群を見まわしていて、みんなと共有したいたくさんのクールなことを見つけた。 出力に色付けする 出力文字列を、成功した時は緑に、失敗した時は赤に、警告は黄色に色づけしたいと思うことはたくさんあるだろう。 NORMAL=$(tput sgr0) GREEN=$(tput setaf 2; tput bold) YELLOW=$(tput setaf 3) RED=$(tput setaf 1) function red() { echo -e "$RED$*$NORMAL" } function green() { echo -e "$GREEN$*$NORMAL" } function yellow() { e

    私が他人のシェルスクリプトから学んだこと | Yakst
    wasai
    wasai 2013/08/21
    これは良いね
  • 1