cles::blog 平常心是道 blogs: cles::blog NP_cles() « 激辛ペヤングが辛いというので・・・ :: 日本橋 Stove (ランチ・ハンバーガー編) » 2012/02/24 Device eth0 has different MAC address than expected, ignoring. というエラーにハマる networking linux systemmanagemant 133 2へぇ Linux マシンに NIC を追加したら ssh ができなくなってしまったのでコンソールでネットワークを restart してみたら 「Device eth0 has different MAC address than expected, ignoring.」 という表示がでて eth0 が up 出来なくて困りました。エラーから /etc/sy
環境 RHEL5 ( ntp-4.2.2p1 ) RHEL6 ( ntp-4.2.4p8 ) NTPは結構微妙な修正を入れてくるのでバージョンが異なる場合は注意が必要。 manが当該バージョンの情報源としてはまず優先。 最近の変更 RHEL6ではRHEL5で /etc/init.d/ntpd のみで行っていたことを /etc/init.d/ntpdate と /etc/init.d/ntpd に分離している。 ntpd起動前のntpdate実行について分離している。ntpdを使うのであればntpdateも同時に有効にするべき(ntpdate実行を避けたい場合以外)。 設計 何もよりも先に 『参考』にあげた富士通の『Linuxユーザーズマニュアル RHEL6編』がNTPの説明として詳しい・わかりやすい。まずはこれを読む。 NTPサーバの階層設計 NTPを使う目的は『正しい時刻の維持』と『時刻
通りすがりの貴方・・・・ /proc/meminfoのあっちの値とこっちの値を足したら、なんでそっちの値と同じにならないの・・・・ と悩んだことありますよね? /proc/meminfoは、カーネルが内部的に管理している枠組みでのメモリ情報をそのまま出しているので、残念ながらユーザ視点で知りたいメモリ情報とは一致しません。 とはいえ、変な解釈をして無意味に悩まないために、それぞれの値の意味合いと項目間の関係を知っておくのは有意義です。私の理解の範囲で、それらの関係をまとめていきます。 #私の理解も完璧ではないので、間違いあればやさしくご指摘お願いします。 参考資料 http://mkosaki.blog46.fc2.com/blog-entry-1007.html 2011/09/07 追記: tmpfsがSwapCachedに含まれるのは幻想でした。tmpfs=Shmemに修正しました。
This domain may be for sale!
Linux環境におけるioDriveパフォーマンスの確認方法 パフォーマンスのテスト方法として以下をご紹介いたします。 kbを参照しながら実行される方が多いと思いますが、あくまでも本記事は翻訳版ですので 差異がある場合には原文を正としますので、補足資料としてご利用下さい。 また、注にもございますが、注意:下記で紹介するライト性能の測定方法は、ioDrive上のデータ(ファイルシステム)を破壊します。ioDriveを再度マウントするには、改めてファイルシステムを作成しなおす必要があります。 という点はご注意下さい。 パフォーマンス面をテストする方法としては実際の利用環境でHDDとioDriveでの実際アプリケーション、DBの実行速度を計測する事が一番近道だと思います。(バッチ処理時間before xxx時間→after yyy分とか) その場合のtipsは後日・・・下記文書をベースに作成 V
外部記憶装置のデータをページ単位でメモリ上に保存するしくみ。 空きメモリは積極的にページキャッシュとして使用される。(空きメモリが少ないからといって、メモリが足りないとは言い切れない) バッファキャッシュを含む。 read ページキャッシュから読み込む。 ページキャッシュ上に存在しないとき、外部記憶装置から読み込む。 write ページキャッシュ上に書き込む。 書き込まれたページはDirtyなページ(=外部記憶と同期していないページ)となる。 Dirtyなページは後でまとめて外部記憶に書き込む。 ページキャッシュ経由でデータがやり取りされる。 +------------------------------------------+ | ファイルシステム、mmap、スワップ処理など | +------------------------------------------+ read↑ ↓w
引き続きTPC-Hの検証。 Linux I/O Schedulerには4種類ありますが、新久保君の TPC-Cの検証で Linux I/O Schedulerによるパフォーマンスの違いは無い という結果が出ています。 が、今回はおどろくべ結果が!!! blocksizeLinux I/O SchedulerElapsedQphH@32GB 32KBcfq3,342 sec986 32KBnoop678 sec4,704 Linux I/O Schdulerを noopに変えただけで約5倍のパフォーマンスアップとなりました! SSDの場合、ディスクヘッドのシークが無いので、何もスケジュールしない noopが有利だと言われていますが、こんなに異なるとは予想外。 リソース消費量についても処理時間を裏付ける結果となりました。 throughputは 133MB/secから 652MB/secへ。
Linuxサーバにおけるパフォーマンス高速化のための設定 CentOS5、Ubuntu、Debianで実行してみたもの。効果あった気がする。 ■ディスクチューニング 参考URL http://www.itmedia.co.jp/enterprise/articles/0707/19/news012.html http://www.avant-tokyo.com/linux/hdparm.html hda表示=IDE sda表示=SCSIorSATA sdaの場合には以下のいくつかのパラメータは無効 # hdparm -Tt /dev/hda 読み出しテスト # hdparm -v /dev/hda パラメータ確認 # hdparm -c3 /dev/hda 32bitモード処理 # hdparm -u1 /dev/hda 割り込み処理対応 # hdparm -d1 /dev/hda DMA
8月版 SSDをめぐる議論に浮かび上がるベンダ模様 小崎資広 2009/9/8 お久しぶりです。先月は「セキュリティ&プログラミングキャンプ2009」の準備があまりにも忙しくて、急きょお休みしてしまった筆者です。 8月は、2.6.31がリリース間近なこともあり、実験的なパッチの投稿は少なかったように思います。唯一、Jens Axboe(blockレイヤのメンテナ)による矢継ぎ早の超大型パッチの投稿が目立っていましたが、多くの開発者がサマーバケーション中なので、反応はイマイチ。そんな中、SSD周りの議論が強烈に面白い展開をみせていたので、大きく取り上げてみました。来月は、Jensパッチか2.6.31リリースの特集になる予定です。 それでは、どうぞ。 混迷深めるdiscardリクエスト ■全面書き直しが必要? 8月15日、Nitin Guptaがswapサブシステムに新しい通知機構の追加を提案
RHELのI/Oスケジューラの変更方法。 環境によっては結構差が出てくるので、何がベストとは言い難い。 簡単にテストできるので環境に合わせて最適なスケジューラを設定しよう。 KVMではdeadlineスケジューラが推奨されている。 LinuxのブロックデバイスI/Oスケジューラはデバイス単位で指定されている。 現在の設定を確認するには、sysファイルシステム以下のblockを参照する。 # cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq] こんな感じで出力されて、[]で囲まれているものが現在の値だ。RHELではcfqがデフォルト値となる。 この値は動的に変更可能で、変更するには設定したいスケジューラ文字列を上記のsysファイルシステムに書き込むだけ。 # echo deadline > /sys/bloc
パソコンを買いました。 CPU:Intel Core i5-2400S Motherboard:ASUS P8H67-M EVO Memory:Patriot PSD38G1333KH 4GB×2 2個 SSD:Intel X25-M G2 120GB HDD:HGST Deskstar 5K3000 2TB Power Supply:Owltech Xseries SS-650KM 今回はOLIOSPECさんのMicro Monster H67 Super Silentをカスタマイズして注文しました。デスクトップ機をリプレイスするのは実に9年ぶりなのですが、最近のパソコンはすごく良いですね。速くて静かで低消費電力です。本日はこのパソコンを使って、近年のLinuxにおけるSSD事情を確認していきたいと思います。 TRIMとは 近頃では定番SSDの座をすっかりCrucial RealSSD
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
CentOS 5.x で、次のように sudo コマンドを実行すると、次のようなエラーがでますよね。 $ sudo service httpd restart sudo: service: command not found これは、当然ながら /sbin にパスが通っていないからです。 PATH を見てみると、次のような感じになっています。ちなみに sudo する前の通常ユーザ naoya のシェルは bash で .bashrc などはデフォルトのまま何も変更していません。 $ sudo sh -c 'echo $PATH' /usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/naoya/bin この PATH に、/sbin や /usr/sbin を追加するには、/etc/sudoers に次の内容を追加します。 $ sudo
LinkedIn YouTube Facebook X, formerly Twitter Quick Links Downloads Subscriptions Support Cases Customer Service Product Documentation Help Contact Us Customer Portal FAQ Log-in Assistance Site Info Trust Red Hat Browser Support Policy Accessibility Awards and Recognition Colophon Related Sites redhat.com developers.redhat.com connect.redhat.com cloud.redhat.com Red Hat legal and privacy links Abo
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
Filesystem Hierarchy Standard(ファイルシステム・ヒエラルキー・スタンダード、FHS、ファイルシステム階層標準)は、Linuxを含むUnix系オペレーティングシステム (OS) での主なディレクトリとその内容を定めたものである。大部分において、BSD系のディレクトリ階層を基にして拡張し定式化している。 主要ソフトウェアおよびハードウェアベンダーからなる非営利組織Linux Foundationが保守管理しており、HP、レッドハット、IBM、デルといったベンダーが参加している。 2020年11月(2020-11)現在の最新版は3.0で、2015年6月3日に発表された[1]。 多くのLinuxディストリビューションはFHS準拠を方針として宣言し、FHSにしたがっている[2][3][4][5]。 もともと、UNIXやUnix系OSには、/etcや/binや/usrなど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く