nginxにLion付属のab（ApacheBench）を実行したら失敗するときの解決ログ
nginxにab（ApacheBench）を実行すると失敗してた うちのサーバは、さくらのVPSにてnginxがフロントにいて、そこから内側のapacheとかRackとかNodeに回しています。 そんなこのサーバにLion付属のabを実行すると失敗していましたが、自力でhttpdから httpd-2.4.1.tar.bz2を取得してmake。abだけ新しいのに差し替えましたら解決しました。 問題の確認から解決まで まずは問題の発生している状態から。 apr_socket_recv: Connection reset by peer (54) うーん？ ただのgif画像とかでも同じように切られるのでapacheとかは無罪と判定。（静的ファイルの配信はnginxがしてるから） % ab -n 100 -c 2 http://havelog.ayumusato.com/ This is Apac
vim-python-pep8-indentプラグインで幸福実現した
Pythonのコーディングスタイルチェックにはflake8を使っていたのだが、インデントルールの次の二つは守れないでいた。 E126 continuation line over-indented for hanging indent E128 continuation line under-indented for visual indent 具体的にはvimのインデント(Visualモードで範囲選択して = )だとpep8のインデントルールになってくれないので、ignore = E128,E126 していた。 そこで、@seizansに教えてもらった vim-python-pep8-indent を入れたらvimのインデントがpep8準拠になり、ほぼノーコストでpep8対応が完了できるようになった。これは良い。 .vimrcの記述は次の通りにした。 " flake8 NeoBundle
Dungeons & Parties の開発的な話 | それなりブログ
使ったライブラリや素材などはクレジットにまとめています。 JSに詳しい人が見るとわかってしまうんですが、超・安定指向です。枯れた技術万歳！ 他、そのために作った自前のライブラリがいくつか。 このブログのサイドバーに置いてある jQuery Plugin と npm のライブラリ群がそれです。 生 Backbone.js のみです。 node で実行できることだけを条件に、あんまり考えないで選定しました。 ゲーム作りのフレームワークとしては、 他のJSフレームワークをたしなむ程度にしか触ったことがないので比較は難しいですが、 無いよりは有ったほうが遥かに良いことだけは確かでした。 この辺は、一言では言えないので、別記事にするかもです。 おそらくですが、Web ページっぽいのを想定して作り込まれている他フレームワーク、 例えば、AngularJS, Knockout.js, Ember.js
Benchmark uWSGI vs gunicorn for async workers
All of the WSGI benchmarks I found were pretty outdated or didn't include async results, so I decided to do some benchmarking myself. I know there's other options for running python WSGI applications, but I settled on just 2: gunicorn, which has the advantage of being pure-python and uWSGI, which has the advantage of being pure-C. I ran these tests on a m1.large Amazon AWS EC2 instance using the l
見落としがちなLinuxのWEBチューニング | Act as Professional
WEBコンテンツ配信にLinuxを使うのは一般的になりましたが、CentOSやUbuntuをはじめ、大抵のディストリビューションが低スペックなマシンでも動くような初期設定になっています。 トラフィックの上限でもない CPUリソースの枯渇でもない HDDのIOが遅い問題でもない コンテンツが重くなる(接続できない) というケースで、見落としがちなLinuxのネットワーク周りのチューニングについてです。 iptables関連 iptablesを使用している場合、下記のパラメータを注意して下さい。 /proc/sys/net/ipv4/ip_conntrack_max ip_conntrackに記録できる最大値です。65536あたりが初期設定になっているかと思います。これだとパケットの取りこぼしがすぐに起きてしまいます。1コネクションあたり約350バイト消費するので、実装されているメモリに応じて
AWS Redis on ElastiCache のBenchmark をしてみた - tech.guitarrapc.cóm
実は Redis on ElastiCacheに関しては、先月2013年9月5日に AWSからリリースされてから、すぐにベンチマークをとっていました。 が、記事にするのを忘れていたという、いつもの有様です。 さて、Redis on ElastiCacheに関しては、他にも既にいくつかのベンチマーク記事があります。 まめ畑 - ElastiCache Redis Engineのベンチマークともろもろ インフラ備忘録 - Redis on ElastiCache を試しています Medium - Benchmarking Redis on AWS ElastiCache 今回は、EC2で Redisを実際に高トラフィックで使っている立場から、EC2とRedis on Elastic Cacheを比較したベンチマークを公開します。(他の記事とは違いm2.4xlargeベースの検証です) 目次 目
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
kernelチューニング
linuxサーバのOS全体に効くカーネルパラメータのチューニング箇所と その設定値、またその理由をまとめておく。 あくまで自分の環境ではこうした、というだけであり、 提供するサービスごとに検討が必要である。 どこをどう変更するのか、または変えないのか、その判断材料にはなるだろう。 ※ユーザ単位でシステムリソースに制限をかける場合をこちらを参照してほしい。 以下は/etc/sysctl.conf で設定するものとする。 ● 大規模サイト用チューニング kernel.pid_max 動作：pidの最大数 設定値：131072 理由：pidを枯渇させない vm.max_map_count 動作：mmapやmalloc時にメモリを仮想空間にマッピングできる最大ページ数 設定値：300000 理由：マッピングできなくなる事態を防ぐ net.core.somaxconn 動作：接続(ソケット)キューの
[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority
前回の続き。 パケット自体を零さずに処理に入った後にSYNを落とすのは以下3パターン。 syncookie無効時にsynのbacklog(tcp_max_syn_backlog)が溢れている listenのbacklogが溢れている(3way-handshake完了後のaccept待ち接続) net.ipv4.tcp_tw_recycleの制限に抵触 で、今回問題になっていたのは最後のtcp_tw_recycleへの抵触だった。 現象として発生しうるのは、以下の条件をすべて満たす場合 サーバ側でnet.ipv4.tcp_tw_recycleが有効 TCPタイムスタンプオプションを使用 同一IPからの接続でセッションを跨ぐとセットされるTCPタイムスタンプの値が戻る場合がある 最後の条件が微妙だが、TCPタイムスタンプの値としてセットされる値は起動時を 起算時にしていたりと実装によって初期値
![[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority](https://cdn-ak-scissors.b.st-hatena.com/image/square/264702d4cb37ced3c2fd5dda6a1368c235356862/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127119925553%2F17680117127119930188%2F1557218483)
ローカルポートを食いつぶしていた話 - download_takeshi’s diary
ここのところ、お仕事で管理しているシステムで、夜中に負荷が急上昇する事象が発生しており、夜な夜な対応に追われていました。 （このブログ書いている今も、負荷がじわじわ上昇中なんですが・・・） で、いろいろと調査した結果、ようやく糸口がわかってきました。 結論から言うと、ローカルポートなどのネットワーク資源を食いつぶしていたようです。 以下、調べていってわかったことなどのメモです。 トラブルの事象 運用しているのは Apache2.2 + mod_perl2 なwebサーバで、リスティング広告システムの配信系です。 リスティング広告の配信のシステムって一般的にロジックが複雑でいやーな感じなんですが、このシステムもご他聞に漏れずかなりのひねくれ者で、しかもトラヒックは結構多めです。システム全体で、日に1000万〜2000万クエリくらいかな。幸か不幸か、このご時勢においてもトラヒック的には成長し続
Linux Clusters Overview
Author: Blaise Barney, Lawrence Livermore National Laboratory This tutorial is intended to be an introduction to using LC's Linux clusters. It begins by providing a brief historical background of Linux clusters at LC, noting their success and adoption as a production, high performance computing platform. The primary hardware components of LC's Linux clusters are then presented, including the vario
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
