タグ

ブックマーク / blog.father.gedow.net (8)

  • systemd時代に困らないためのlimits設定 | 外道父の匠

    数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール/SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上

    systemd時代に困らないためのlimits設定 | 外道父の匠
  • 現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠

    RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね(キリッ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした

    現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
  • サービス品質の改善効率を高める仕組み | 外道父の匠

    最近うぇぶ業界では、開発効率や構築効率を求める動きが活発のように見受けられますが、ここで改善効率について手を伸ばしてみましょう。 改善効率とは、開発後期やサービス開始後の運用フェーズにおいて、クソコードやクソクエリ、データの蓄積によるレスポンスの悪化などを、自動的に検知し、開発者にオラオラ改修をプッシュするための仕組みのことでございます。 はじめに ここで紹介する内容はドリコムで実際に運用しているものですが、別にドヤ顔するようなものではなく、中規模以上の企業ならば似たようなことやそれ以上のことをやっているであろう、至極当然な内容です。それでも、それなりに種類が増えてきたことと、それなりの効果を得られていることが実感できているため、いったんまとめてみようと思った次第です。 ウチのサービスのサーバーサイドは Ruby on Rails + MySQL が基なので、その対策手法になります。WE

    サービス品質の改善効率を高める仕組み | 外道父の匠
  • OpenStack+KVMのCPUオーバーヘッド調査 | 外道父の匠

    調べる気になった事の発端は、Cinder+Cephのボリュームに対してMySQLのtpccベンチマークを取ってみた時に、vCPU=1 でVM内では CPU : 100% なのに、KVMプロセスのCPUが 300% を超えているのを見つけたことでした。 KVMは仮想環境なので当然オーバーヘッドが存在するのは覚悟済みですが、想像以上にホストOS上でCPUっていたために、良い子の私は地道に調べ始めるのでした。 検証環境 CPUとメモリ ホストOSのcpuinfoの表示ですが Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.00GHz VMだとこう Intel Xeon E312xx (Sandy Bridge) まぁほどほどに最近の、お値打ち価格になってきた低電力版なナイスCPUです。 VMへは 1~4vCPU 割り当てて検証しています。 VMに割り当てたメモリは全て

    OpenStack+KVMのCPUオーバーヘッド調査 | 外道父の匠
  • キャパシティプランニング 発表資料 | 外道父の匠

    久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを1つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい

    キャパシティプランニング 発表資料 | 外道父の匠
  • 原因調査用Linuxコマンド | 外道父の匠

    サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 <追加したコマンド> * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot

    原因調査用Linuxコマンド | 外道父の匠
  • ulimitが効かない不安を無くす設定 | 外道父の匠

    limits.conf に書いても ulimit に効いていない、というのはよくある話です。 ulimit が少なくて困ったことはあっても、多くし過ぎて困ったことはほとんどないでしょうから、ドーンと全条件下でulimit設定を効かせる方法を紹介します。 ulimitが効かない問題 だいたいこんな内容だと思います。 SSHログインだと効かない su すると効かない OS起動時に自動起動したデーモンに効かない 普通はデーモンに効けばよいので、当に困ったら起動スクリプトに直接書いたりしますが、方法としてはイマイチなのでちょっと工夫をします。 その前に・・・ PAMについて PAMというユーザー認証システムについてはググっていただくとして、よく出てくる /etc/security/limits.conf という設定ファイルは、PAMを通る条件下でしか有効になりません。 ではPAMを通るとはどうい

    ulimitが効かない不安を無くす設定 | 外道父の匠
  • Percona XtraBackupの機能紹介 (1) 差分バックアップ | 外道父の匠

    誰もが一度は「差分だけバックアップできたらな」と思うところですが、なんとXtraBackupには差分バックアップがあるのです。 Incremental Backups 巨大に膨れ上がったデータベースの更新分だけを抽出して、別サーバで完全体に戻しておく、といったことができるため、より効率的なバックアップを行うことができます。少なくともバイナリログによる差分バックアップとかダサいことはやる必要がなくなります。 メリットとデメリット メリット 差分バックアップの処理時間は全体バックアップより短くなります 差分バックアップは容量が変更分だけのためかなり小さくなります ベースバックアップから好きな差分のところまで復元できます デメリット リストアのために差分の適用処理が必要になります ベースと差分のバックアップ世代管理が複雑になります # まず全体 mkdir -p /backup/base xtr

    Percona XtraBackupの機能紹介 (1) 差分バックアップ | 外道父の匠
  • 1