タグ

kernel tuningに関するkazu_0のブックマーク (12)

  • CentOS7再起動でsysctlで設定したカーネルパラメータが反映されないのはTunedが原因だった - YOMON8.NET

    sysctlで永続的なカーネルパラメータ swappiness 設定をしたはずなのにOS再起動しても設定が反映されない事象で少しはまりました。Tunedの動きを制御できれば解決できました。 再起動後にsysctlの設定が反映されない 空きメモリがあるにも関わらずSWAP沢山使ってしまうサーバがあったので、swappinessを調整しようとしました。 まずは暫定対応、問題無く設定でき、SWAPも使わないようになりました。 # cat /proc/sys/vm/swappiness 30 # cat 1 > /proc/sys/vm/swappiness # cat /proc/sys/vm/swappiness 1 次にパラメータを永続化するためにsysctlの設定を行いました。 # cat /proc/sys/vm/swappiness 30 # echo "vm.swappiness =

    CentOS7再起動でsysctlで設定したカーネルパラメータが反映されないのはTunedが原因だった - YOMON8.NET
  • Linux におけるスレッド数の上限 | yunabe.jp

    並行 (Concurrent) 処理を実装する方法としてスレッドは非常に強力なツールです。 スレッドを使えば同時に1つの処理しか行えない既存のプログラムに大きな修正を加えることなく、 並行処理を実装することが可能です。 またイベントとコールバックを複雑に組み合わせた非同期的なプログラムに比べて、 同期的なプログラム (例えばファイルの読み込みにコールバックが出てきたりしない普通のプログラム)は プログラムの流れを自然に書くことができ、 可読性・保守性・テスト、デバッグのしやすさの面で遥かに優れています。 スレッドを使うとプログラムをそれほど複雑・難読化にせずに並行処理が実装できます。 一方でスレッドを使った並行処理には欠点もあります。 欠点の1つは、スレッドモデルでは1つの処理に対して1つのスレッドを用意するので、 システムのスレッド数の上限で同時に行える処理の数が決まってしまう点です。

  • Bad gateway errors at load on nginx + Unicorn (Rails 3 app)

    I have an Rails (3.2) app that runs on nginx and unicorn on a cloud platform. The "box" is running on Ubuntu 12.04. When the system load is at about 70% or above, nginx abruptly (and seemingly randomly) starts throwing 502 Bad gateway errors; when load is less there's nothing like it. I have experimented with various number of cores (4, 6, 10 - I can "change hardware" as it's on cloud platform), a

    Bad gateway errors at load on nginx + Unicorn (Rails 3 app)
  • LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々

    ということに、(今更?)気付いたお話です。 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

    LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々
  • TCP tuning for your database

    Lately lots of new fascinating technologies are used to build even more fascinating new solutions, and solutions nowadays even run on distributed environments, not just on single server. These servers usually communicate using TCP – standard, that has been here long before gigabit (or ten megabit) ethernet or dawn of LAMP, and needs to be kicked a bit, to work properly. In our environment we have

    TCP tuning for your database
  • Pgpool-IIの接続性能の改善 | Let's POSTGRES

    SRA OSS, Inc. 日支社 石井 達夫 はじめに 記事は2013年のPostgreSQL Advent Calendar の 12/17 の記事です。pgpool-IIに多数のクライアント同時に接続すると、極端にレスポンスが落ちることがあります。ここではその原因と改善方法について考えます。 pgpool-IIはpre-fork型のアーキテクチャ pgpool-IIは、複数のPostgreSQLを使ったクラスタシステムを構築できるミドルウェアです。pgpool-IIでは、num_init_childrenというパラメータの数だけあらかじめプロセスを起動(pre-fork)しておきます。クライアントからの接続要求があると、そのプロセスの一つがカーネルから選択され、クライアントからの接続を受付けて、処理を開始します。これはApacheなどと同じ方式で、あらかじめプロセスをフォークして

    Pgpool-IIの接続性能の改善 | Let's POSTGRES
  • listen backlog 【3.6】 - Linuxカーネルメモ

    (*1) backlog(512)はtcp_max_syn_backlog(400)より大きいので、400を切り上げた512がsyn backlogのサイズになる。 syn backlogのサイズを大きくしようとするには、以下の点に注意する。 (a) net.ipv4.tcp_max_syn_backlogを大きくする (b) listen()で指定するbacklog値を大きくする(apacheならListenBackLogディレクティブで指定できる) (c) backlogの値自体はnet.core.somaxconnに切り詰められるため、net.core.somaxconnの方も大きくしておく。 syn backlogの最大サイズはbacklogサイズに基づいて決まるため、net.ipv4.tcp_max_syn_backlogを大きくするだけでなく、backlog自体が大きくなるよう

  • プロダクション環境へのデプロイ — Xitrum Scala Web Framework Guide 3.18 ドキュメント

  • 高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋

    はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか? 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の2倍や3倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立

    高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
  • Linux(CentOS6)カーネルチューニングのメモ | ちゃんと覚えておけよ?

    今回行った /etc/sysctl.conf の設定内容は書きの通りです。 各パラメータの説明はコメントとして残しておきます。 # 共有メモリの最大サイズ。サーバーの搭載メモリ(1GB)に合わせて変更 kernel.shmmax = 1073741824# システム全体の共有メモリ・ページの最大数 kernel.shmall = 262144# システム全体のプロセス数の上限 kernel.threads-max = 1060863# システム全体のファイルディスクリプタの上限 fs.file-max = 5242880# RFC1323のTCPウィンドウ スケーリングを有効にする。 # 64K以上のTCP windowを使えるようになる。 # 巨大なファイルを転送する時に問題になった場合は無効にすると解決されることもある。 net.ipv4.tcp_window_scaling = 1#

  • ま鉄系 » 月100万リクエストを支えるサーバの裏側を公開します

    福田です。今日は、月100万リクエストを超えるアクセスを支えるこのVPSのシステム構成とかを公開しようと思います。その気になれば3コア、2GBしかないメモリでも余裕でさばけるっていうわけです。 OSは何使ってるの?OSは、日で業務に使用しているところは少ないUbuntuのLTS(バージョンは書きません)を利用しています。 Ubuntuを使う理由としては、HHVMとかを入れやすいところにあります。その他のソフトウェアもCentOSとかRHELより豊富だったりします。あとは、慣れっていうのもあります。サーバで使用しているソフトウェアは?100万リクエストにさくさく応えるために、Nginxを利用しています。表面上はフルスロットルってなっていますが、これはNginxのソースコードをいろいろ書き換えたりして運用しているためにあえて変えてある仕様となっています。Nginxでも、何重にもキャッシュをか

  • いますぐ実践! Linuxシステム管理

    「いますぐ実践! Linux システム管理」はこちらです。 メルマガの解除、バックナンバーなども、以下からどうぞ。 https://www.usupi.org/sysad/ (まぐまぐ ID:149633) その他、作者に関するページは、概ね以下にございます。 https://www.usupi.org/kuri/ (まぐまぐ ID:126454) http://usupi.seesaa.net/ (栗日記ブログ) https://twitter.com/kuriking/ (twitter) https://facebook.com/kuriking3 (facebook) https://jp.pinterest.com/kuriking/pinterest) https://www.instagram.com/kuri_king_/ (instagram) [バックナンバーのトップへ

  • 1