最近、MySQLのパラメータの調整をする機会があったのですが、特定のパラメータを変更した際に、メモリの消費量にどう影響するのか、というのを調査する際に、インターネッツを彷徨ったところ、サイトによって書いてあることにバラつきがあったので、自分でもまとめてみることにした。 結論から書くと、参考にしたのは以下のオライリーの書籍「MySQLトラブルシューティング」で、記述が一番わかりやすく書かれていた。 このエントリは、この書籍の 「3.9.3 オプションの安全値を計算する」 にて記載がある内容をまとめたものになる。 MySQLトラブルシューティング 作者:Sveta SmirnovaオライリージャパンAmazon 著者について Sveta Smirnova(スヴェータ・スミルノヴァ): Oracle社MySQLサポートグループ・バグ検証グループの主席テクニカルサポートエンジニアとして毎日MySQ

今年の4月頃の話を思い出しながら書きます。 自分のブログのコピーサイト見つけた。まるっとスクレイピングしてコピーしていそうな雰囲気だなぁ。— Y.Namikawa / id:rx7 (@namikawa) April 7, 2020 昔から自分の作業ログ的に、このブログを使っていることもあって、こういう場合どうやるのだっけなぁ、と自分自身のブログコンテンツを探すときにもググったりするのですが、その時に自分のブログサイトに書いたはずのコンテンツが、違うドメインのサイトに丸々と掲載されているのを見つけた場合・・・！の話。 ためしにエントリーのタイトルで検索してみる 何が起こったのかよくわからなかったので、そのブログエントリーのタイトルをそのまま入れてみて Google 検索をしてみたところ・・・、 検索結果には、自分のブログサイトが1番目に出てきましたが、上から4番目にコピーサイトが出てきます

9年ほど前にこういうエントリを書いたのですが、まだそれなりに見られているようなので、最近はどうなのかなーと、再検証・再計測してみたエントリーです。 ↑の過去エントリにも記載しているのですが、SSH/SCP では暗号化方式（強度）によってファイル転送のスループットが変わります。 もちろん、オープンなネットワークでやるにはセキュリティがー、とか、インターナルでやるなら、そもそも netcat (nc) でいいやんー、とか、そもそも大量にファイル数あるなら、事前に固めてしまえー、とか色々あると思うのですが、本エントリではあくまで暗号化方式 の違いでスループットがどう変化するのか、それはどのくらいスループットが出るのか、を確認したログとなります。 ベンチマークで利用した環境 Google Compute Engine (GCE) の インスタンス (n1-highcpu-4) を2台準備しました

※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2010/06)です。 ※ 情報が古い可能性もありますので、ご留意ください。 どこかのサンプルで、Reference に "a" が付くのを見かけてどういう意味かと思えば、ユーザ(u)・グループ(g)・その他(o)の全てを指定する、という意味なのね。 今まで、普通に省略していたので気にしたことなかった。というか、私の場合、8進数でモード指定することが多い。 Reference Class u ユーザ g グループ o その他 (全ユーザ) a 上記3つ全て ugo と指定するのと同じ

情報ソースとして割とあふれている話なんですが、前提が足りない情報が多いので、補足すべく書いておきます。 と、その前に、mail コマンドで SMTPサーバ経由のメール送信をやりたくなった、そもそもの動機を書いておきます。 GCE(Google Compute Engine)で作ったサーバに、nagios をセットアップしていて、アラートをメールで飛ばしたい。が、現在はGCE のインスタンスから宛先{25, 465, 587}番ポートへのメール送信は仕様として禁止されている。なので、GCE では sendgrid や mailgun、Google Apps を使ってメール送信してくれ、とドキュメントに記載されているのですが、まぁ色々な事情と対象がアラートメールという性質もあり、GCE 外部で既に動かしているSMTPサーバを経由して送りたい。 で、nagios のメール送信は、内部的に mai

メモメモ。泥臭い話で面白かったです。 「大規模Redisサーバ縮小化の戦い」 駒井 祐人 氏 (株)アカツキ ゲームのサーバサイド機能開発、インフラの設計構築・保守運用 Redisとは インメモリDB 5種類のキーバリューのデータ型 ファイル永続化オプション システムの問題点 EC2サーバが20台に対して、AWSのElasticCache(Redis)が64台あった なぜ64台あったかというと、リリース直後にRedisの負荷問題があり、8台 => 64台になった 調査するとkeys("")を実行している箇所があった 当然お金がかかる(cache.m3.large * 64台 = 約135万円/月) 冗長化しんどいし、設定ファイルの記載も辛い ので、縮小化と冗長化の対処をしたい 現状整理 格納されているデータ フレンド情報、セール情報、ランキング情報 キーの件数 1サーバに8DB、1DBあた

メモった。間違い等あるかもしれませんが、その場合はごめんなさい。 Gunosy 2011.09リリース 現在900万DL突破 エンジニアは現在26名 2014.11は16名、2013.11は7名、2012.11は4名 クライアント+QAは5名、Web+APIまわりは5名、インフラは1名とかとか Gunosyの開発 API: Golang パートナー・広告主への管理画面: Rails バッチ・内部向け: Django or Python バージョン管理: GitHub 構成管理・デプロイ: Chef (+OpsWorks) 開発の特徴 小さい単位で作ってすぐ捨てる マイクロサービス的な 機能が増えすぎたら分割 メンテするよりリプレース サーバにログインされて困る事 信頼できないビルド・デプロイ 開発者の手元でビルドすると、どの断面なのかわからずトラッキングできない プロダクションに上がってい

全国1000万人の・・・からはじまるエントリでおなじみのRyuzeeさんのブログエントリで既に紹介されていますが、数日後となる5/22に「Chef実践入門 -コードによるインフラ構成の自動化-」という書籍が出ます。(5名による共著です) Chef実戦入門 Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) 作者: 吉羽龍太郎,安藤祐介,伊藤直也,菅井祐太朗,並河祐貴出版社/メーカー: 技術評論社発売日: 2014/05/22メディア: 単行本（ソフトカバー）この商品を含むブログ (19件) を見る 本書は"実践入門"という名の通り、これからChefを触ろうとされている方から、既にChefを触っている方でよりChefを活用していきたい方まで幅広く、Chefに関しての知識を習得できる内容になっていると思います。 書籍の細かい内容に関しては、エントリの下

MySQL 5.5 のホストキャッシュに関するメモ。 詳細は以下ドキュメントに全て書いてある。(英文) MySQL :: MySQL 5.5 Reference Manual :: 8.12.5.2 DNS Lookup Optimization and the Host Cache シーケンス 新しいクライアントから接続があると、サーバはそのIPアドレスからホスト名がホストキャッシュにあるかチェックする。 無ければ、サーバはホスト名を解決することを試みる。 まず、IPアドレスからホスト名をチェックし、そしてホスト名からIPアドレスをチェックする。で、その結果をオリジナルのIPアドレスと比較し、同じであることを確認した後、ホストキャッシュに格納する。 キャッシュが一杯の場合は、最も長い時間使われていないエントリが破棄される。 名前解決 OSがサポートしている場合、スレッドセーフな geth

hostsファイルの記載に誤りがあるまま、telnetコマンドを実行した。 で、誤りに気付き、hostsに記載のIPアドレスを修正し、telnetコマンドを再度実行したが、なぜか古い記載のアドレスに接続しにいく。 むむっ、と思って、straceしてチェックしたら、 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0↑の通り、nscdを見に行っておった。 # nscd -i hostsということで、↑のような感じで、nscdの持っているhostsのキャッシュを破棄して、無事期待通りの動作になった。 ・・・たまに調べるから、ここに残しておく。 それでは！ =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́ 追記 やっぱりそうだよなぁ。うーむ。 デーモンは( pas

ちょっと調べたのでメモ。 UUID(Universally Unique IDentifier)の詳細については下記リンク先をご参照いただくとして、UUIDの生成については様々なプラットフォームでサポートされているのと、いくつかバージョンが存在します。 Universally unique identifier - Wikipedia UUID と Perl について - daily dayflower バージョン4(完全ランダム生成)を使う前提で、いくつかワンライナーで実行するやり方を残しておきます。 uuidgenコマンド(Linux) $ uuidgen f6574b6b-02f7-4255-865b-dda39dcd0979オプションなしで実行すると、上記の通りデフォルトはバージョン4で返してくれます。 (UUIDの 00000000-0000-X000-0000-00000000

AWS re:Inventで発表されていた、SSDによる高性能ランダムI/O用に最適化されたという、Amazon EC2の新しいインスタンスタイプ「I2インスタンス」が先日使えるようになりました。 インスタンスタイプとしては"i2.*"からはじまるやつです。 I2インスタンスタイプは、特にリレーショナルデータベース、NoSQLデータベース、およびトランザクションシステムによって生成されるI/O集約型のワークロードをホストするように設計されています。最も大きいサイズのI2インスタンスタイプは、4KBのブロックサイズでの計測で、秒間365,000を超えるランダムリードと秒間315,000を超えるランダムライトの性能を発揮します。4つのインスタンスサイズをご利用いただけますので、必要なストレージとI/O性能が高くなのに合わせて、小さくスタートし、スケールアップしていくことができます。 このインス

HAProxyを使う上で、どうやったらパフォーマンスが上がるのかを模索するメモ。 基本的に、万能なパフォーマンスチューニングはないので、今回はCPS(Connections per Second)のパフォーマンスを上げることに焦点を絞ります。CPS(Connections per Second)は、ロードバランサの性能指標の1つとなっている数値です。 あくまで軽くやってみた過程のメモ書きみたいなものなので、まとまりもなく、まだまだ改善の余地があるとは思いますが、何かの参考にしてください。 前提 HAProxyを動かすのに使用した環境は以下の通り。 Server: DELL PowerEdge R420 CPU: Intel Xeon E5-2430L @ 2.00GHz * 2 Memory: 96GB Ethernet controller: Intel Corporation Ethe

HAProxyは基本的にL7レイヤのロードバランサー(リバースプロキシ)なので、バックエンドにいるリアルサーバには、フロントエンドから届いたリクエストが、ロードバランサのIPアドレスからアクセスが来たかのように振舞います。 で、HAProxyはtproxy(transparent proxy)をサポートしているようなので、L4で動く透過型のプロキシとしても振舞うことが出来るようです。ので、ちょっと試してみました。 使ったOSは、CentOS 6.4で、HAProxyは開発版の1.5-dev19です。 参考: Transparent proxy support (www.kernel.org/doc) https://www.kernel.org/doc/Documentation/networking/tproxy.txt Linux kernelのnf_tproxy_coreモジュールを

ロードバランサとかリバースプロキシを使って色々やっていると、HTTPS/SSL対応かー、どうしようかなーみたいなことを考える日がそのうちやってきたりするかもしれません。 さて、最近触り始めたHAProxyなんですが、公式サイトの記載を見ていると、開発版のバージョンだとSSL処理をサポートしているみたいなんですよねー。 Update [2012/09/11] : native SSL support was implemented in 1.5-dev12. The points above about CPU usage are still valid though. HAProxy - The Reliable, High Performance TCP/HTTP Load Balancer ふむふむ、"1.5-dev12"以降のバージョンであれば使えそう。 ということで、前回のエントリ

ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP

気がついたら、1ヶ月以上ブログ書いてなかったのでサクッと。タイトルは半分釣り、半分は本当。 昨日、AWSから新しい世代のHPC向けのAmazon EC2インスタンスが発表されました。"c3.*"からはじまるやつです。 Amazon Web Services ブログ: 【AWS発表】 新世代の数値計算向けEC2インスタンス 安ッ！ で、今朝、下記のブログで知ったのですが、Spot Request(スポットインスタンス)の相場を見ると、"c3.8xlarge"が東京リージョンの1つのZoneで「$0.0001」という状態ｗｗｗ Amazon(Web Services)が大セール！c3.8xlargeがなんと！$0.0001！！ - qphoney記 "c3.8xlarge"といえば、Intel Xeon E5-2680 v2 (2.80GHz)といったIvy Bridge世代のアーキテクチャの

歴史のあるクラウドサービスは、どこもそうなってしまう傾向があるとは思いますが、ホストサーバでの実CPUのアーキテクチャ・世代の違いで、サーバインスタンスのCPUパフォーマンスに微妙な差がついてしまいます。 2006年よりサービス提供しているAmazon EC2でもその傾向があることは割と知られていて、同じ性能だと思って並べて使っていたサーバインスタンスが、同じ処理量にもかかわらず使っているCPUリソースに差がついている、なんてことが起こります。 con_mameさんも、以下のエントリで書かれていますね。 EC2で同じECUだけどCPUは違う - まめ畑 昔は、us-eastでm1.smallのインスタンスをよく使ったもので、その頃はいつもAMDのOpteronプロセッサでしたが、最近では、ほとんどIntel Xeonですし。 ということで、現時点(2013/10)で、EC2インスタンスで使

タイトルの通りですが、IPv6を使っている自ネットワーク環境下から、Amazon VPCにVPN接続し、VPC内のインスタンスとIPv6ネットワーク配下のサーバとを通信(連携)できるようにしてみたログです。 IPv6を使う上での前提条件/要件 まず、今回話をする上での前提となる話ですが、IPv6を使っている自ネットワークの環境は以下のような状態でした。 自ネットワーク内のサーバは、割り振られているIPアドレスがIPv6アドレスonlyのケースと、IPv4/IPv6のデュアルスタックとなっているケースがある。 どちらのパターンのサーバであっても、VPC内のインスタンスと通信したい。 IPv6のアドレスはGUA(Global Unicast Address: つまりグローバルなアドレス)を割り当てている。 通信するサーバ(VPC内のサーバ)もIPv6のGUAを使った宛先にしたい。 と、こんな感

参考までに、AWS(Amazon Web Services)までの通信経路上のASパスの数が短くなったら、どれくらいレイテンシが変わるのか計測してみました。 注意事項として、この手の話は、もちろん環境によって結果が大きく変わるので、参考程度にしかならないかもしれませんが、軽く読んでみてください。 ※ 少々長いので、時間がない方は、最後の"考察・まとめ"だけを読んでもらえればOKですｗ BGPピアを確立する？ 通常、インターネットで目的のホストと通信を行うと、途中途中で多くのネットワーク機器を通過することになります。選択される経路は、接続するネットワークによって大きく異なりますが、(もちろん)そのネットワークからの最適な経路が選択されることにはなります。(ルーターで設定されている) で、当然そのルートは短ければ短いほど、ネットワーク距離が小さくなり経由する機器の数も減るので、レイテンシ(遅延