フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Immutable Infrastructure / これからのWeb, クラウドシステム
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
サーバをメンテする時に便利な Linux コマンド 3つ - bekkou68 の日記
はじめに サーバを運用したり環境を構築したりしていて「あれ。あのプロセスで吐いてるログどこだっけ・・」など困るときがあります。 そんなときに頼りになるかもしれないコマンドを 3つご紹介します。 @madeth 師匠に教えていただきました。 1. proc でプロセスが使っているファイルを見る 困ったこと プロセスの吐くログのパスがどうしても分からない・・。 解決法 (編集 2014/09/10) 知りたいプロセスの ID を調べます。 $ ps aux | grep unicorn deploy 3335 xxx xxx xxx xxx X XX 15:14 0:07 unicorn master -c /var/www/myproject/unicorn/staging.rb -E staging -D プロセスID (この場合は 3335) をもとに root 権限でファイルディスクリ
Docker使ってたらサーバがゴミ捨て場みたいになってた話
Immutable Infrastructure Conference #1
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
sarによるボトルネック発見の手順(というかsysstatの使用法)をまとめてみた - end0tknr's kipple - web写経開発
sar で収集したリソース使用情報が sadf コマンドで TSV として出力 (2014/8/6追記) sar で収集したリソース使用情報が sadf コマンドで TSV として出力できる - 宮川拓の日記 ↑全く知りませんでした 私がよく利用するoption (2013/8/6追記. よく忘れるので) $ sar -r -s 00:00:00 -e 01:00:00 -f /var/log/sa/sa03 ｵﾌﾟｼｮﾝ 内容 例 -q load average $ sar -q -u cpu使用率 $ sar -u -b I/O回数とﾃﾞｰﾀ量 $ sar -b -r ﾒﾓﾘとｽﾜｯﾌﾟ使用率 $ sar -r -s 開始時間 $ sar -s 00:00:00 -e 終了時間 $ sar -e 03:00:00 -f 日付 ※ $ sar -f /var/log/sa/sa03 ※「
Webサーバのメンテナンス、トラブル調査に役に立つコマンド3選 - Glide Note
メンテナンス、サーバのミドルウェア設定、障害対応のときに私がよく使っているコマンド。 先週Webサーバを16台ほどリプレイスした際にも、使って挙動、確認作業をしてました。 コレ系のコマンドは各人の秘伝のタレみたいになってて、他の人が教えてくれることが少ない気がして、 新卒氏のインフラOJT用に専用の資料作ろうかと思ったけど、新卒氏以外でも知ってれば 「よく分からんけど、動かないからインフラ担当者に聞く」みたいなことが 減って自分で解決出来るのではないかと思うので書いておく。 手元のmac、linuxから該当サーバに対して実行するコマンドで ちゃんと該当サーバが外部に向けてサービスが提供出来ているのか、 要は外から確認するためのコマンドです。 調査系のコマンドは オプション、使い方が覚えやすい 手軽に使える 結果が見やすい、理解しやすい というのが重要だと思う。 サーバの中で調査するなら 原
500,000 requests/sec – Modern HTTP servers are fast
A modern HTTP server running on somewhat recent hardware is capable of servicing a huge number of requests with very low latency. Here’s a plot showing requests per second vs. number of concurrent connections for the default index.html page included with nginx 1.0.14. With this particular hardware & software combination the server quickly reaches over 500,000 requests/sec and sustains that with gr
dstatの万能感がハンパない - （ひ）メモ
サーバーのリソースを見るにはグラフ化は重要ですが、推移ではなくリアルタイムな状況、例えば秒単位のスパイキーな負荷を見るには、サーバー上でvmstatやiostatなどの*statファミリーを叩く必要があります。 さて、vmstatはメモリの状況やブロック数単位のI/O状況は見られますが、バイト単位のI/O状況やネットワークの送信、受信バイト数を見ることはできません。 # vmstat 1 procs -----------memory---------- ---swap--- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 4724956 355452 726532 0 0 54 484 3 3 1 0 99 0 0 2 0 0 47
smartd での sector error 復活作業 | ni kvel
家鯖で、Sector Read Error がでていて OS が立ち上がらなかったので、新規に Logical Volume 作って、一旦余っている領域から Logical Volume つくって rsync で同期後立ち上げなおした。 で、復旧後、smartd.log を見ると、家鯖の HDD で smard から↓のような悲鳴があがってた。 smartd[2684]: Device: /dev/sda, 1 Currently unreadable (pending) sectors smartd[2684]: Device: /dev/sda, 1 Offline uncorrectable sectors エラー箇所を調べるため、smartctl を実行 # smartctl –test=short /dev/sda smartctl version 5.38 [i386-r
見落としがちなLinuxのWEBチューニング | Act as Professional
WEBコンテンツ配信にLinuxを使うのは一般的になりましたが、CentOSやUbuntuをはじめ、大抵のディストリビューションが低スペックなマシンでも動くような初期設定になっています。 トラフィックの上限でもない CPUリソースの枯渇でもない HDDのIOが遅い問題でもない コンテンツが重くなる(接続できない)というケースで、見落としがちなLinuxのネットワーク周りのチューニングについてです。 iptables関連iptablesを使用している場合、下記のパラメータを注意して下さい。 /proc/sys/net/ipv4/ip_conntrack_maxip_conntrackに記録できる最大値です。65536あたりが初期設定になっているかと思います。これだとパケットの取りこぼしがすぐに起きてしまいます。1コネクションあたり約350バイト消費するので、実装されているメモリに応じて値を変
はてなブログ | 無料ブログを作成しよう
わたし的棚ぼた一万円選書 急に千葉さんに手渡された封筒、開けてみたら1万円札が1枚。何ごとかと思えば、同期の出張を代わったお礼をもらったらしい。 「葵はワンオペで育児してくれたから」と半分わけてくれました。 泡銭の1万円 これはもう、わたし的1万円選書をしろという思し召しなのでは……
Yapc asia 2011_zigorou
The Ring programming language version 1.7 book - Part 193 of 196Mahmoud Samir Fayed
カヤック流ソーシャルアプリの作り方 インフラ編 - KAYAC engineers' blog
入社4年目にもなってtech.kayac初登場のせいです。 ブログ書けプレッシャーにとうとう屈する時がきました。 これで夢にkyo_agoが出てうなされなくてすみます。(彼はtech.kayacの尻たたき担当でした) 先々月「ぼくらの甲子園!熱闘編」というゲームをモバゲー内にてリリースしました。 これは去年リリースした「ぼくらの甲子園!」の続編です。 モバゲーユーザの方、是非遊んでみてください。 今回はこの「ぼくらの甲子園!熱闘編」がどういうインフラ構成になってるか紹介したいと思います。 注) 題名に「カヤック流」とはつけましたが、カヤックでは多様性を善としている風潮があり、 ゲームによってインフラの構成が違うどころか、利用しているプログラミング言語すら違います。 なので全てのゲームがこのような構成になってるわけではありません。 前提 今回のインフラ構成を決めるに至って考慮した点は「ラクに
3000req / sec と戦う - だるろぐ
ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
趣味開発のためのVPS/クラウド活用術
Future of server provisioning
さくらVPS、DotCloudの次にくるRackhub
http://dl.dropbox.com/u/224433/YAPC2011/index.html
ライブドア様ｘKLab合同勉強会 システムモニタリングツール「Ganglia」の紹介
サーバーを作ろう
