2015年のLinuxのコンテナ技術 | gihyo.jp
2014年は非常にDockerが盛り上がった1年でしたね。 Dockerは2013年の夏ごろから注目を集めはじめました。その後バージョンが0.9となった2014年の春ごろからさらに注目を集めるようになり、それ以降はさまざまなサービスやベンダーがDockerをサポートしたり、Docker関連のプロダクトを出したりするニュースが駆け巡った気がします。 Dockerに関係する勉強会が数多く開催されるようになり、Docker Meetup Tokyoなどは募集が始まった途端に定員に達するという活況ぶりでした。 Dockerは「コンテナ技術」そのものではなく、Dockerがやりたいことを実現するための技術要素の1つとしてコンテナを使っています。このDockerの盛り上がりと共にそれまでどちらかというとマイナーな技術であった「コンテナ」も2014年には非常に注目される技術となりました。 実際、筆者が主
速いしスケールする並列CSVパーサ作った紆余曲折話 - 俺とお前とlaysakura
この記事は↓に移転しました。 laysakura.github.io
インフラエンジニアとしてよく使うコマンド集 - Qiita
私がよく使うコマンド集となります。 参考に頂けたら幸いです。 随時更新するかと思います。 コマンドを打つ前に覚えておく事 ①サーバに負荷がかかるコマンドを打つ場合、下記をコマンドの先頭に付けましょう $ ionice -c 2 -n 7 nice -n 19 # -c 2：ディスクI/Oの実行優先度をベストエフォートで実行 # -n 7：さらにこのコマンドの優先度を低くする # -n 19：プロセスの実行優先度を一番低くする
よくわかるLinux帯域制限 | GREE Engineering
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
緊急コラム： bash 脆弱性（ CVE-2014-6271 ）の影響範囲の調査方法について | NTTデータ先端技術株式会社
Tweet 先週公開された bash の脆弱性について、管理されているサーバーへの影響を気にされている方が多いと思います。そこで緊急コラムとして、影響範囲の調査方法について紹介します。 bash は非常に多くの場面で使用されているプログラムであるため、 bash を呼び出す可能性のあるプログラムや場面をソースコード解析により列挙することは困難です。また、設定ファイルでの指定内容などにも依存する可能性もあり、文章でのお問合せにより漏れの無い的確な判断ができるかどうか不安が残ります。 Red Hat Enterprise Linux （ RHEL ）には SELinux というセキュリティを強化するための機能が搭載されています。しかし、脆弱性の問題に限らず、システムのトラブル予防と適切な対処を行う上では、対象となるシステムの設定や挙動を事前に把握しておくことが重要であると考えます。 今回の脆弱
ウェブリブログ：サービスは終了しました。
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
Tmpディレクトリの活用法について改めて考える | RickyNews
Dominic Alves 普段何気なく利用している/tmpと/var/tmp。 意識して使い分けてる方も分けてない方もいらっしゃるかと思います。 Linuxのファイルシステムとしての存在意義や、一時フォルダとしての機能を改めて意識すると 非常に便利な存在です。 /tmpと/var/tmpの違い 「/tmpと/var/tmpの違いについて述べよ」・・・インフラエンジニアの入社試験の問題に出てきそうですね。 さて単純な解答ですが、システム的なことを言えば以下あたりです。(RHEL) /tmp /var/tmp どちらもディレクトリ配下はtmpwatchコマンドにより監視されファイルの削除が組み込まれています。 $ cat /etc/cron.daily/tmpwatch #! /bin/sh flags=-umc /usr/sbin/tmpwatch "$flags" -x /tmp/.X1
ssコマンドはバグと地雷の塊なのでnetstatの代わりにならない - ろば電子が詰まつてゐる
既に有名な話ですが、CentOS 7およびRed Hat Enterprise Linux 7からはifconfigコマンドやnetstatコマンドが非推奨となり、デフォルトインストールすらされなくなりました。代替として、ifconfigコマンドはipコマンド、netstatコマンドはssコマンドが用意されています。 というわけでさっそくssコマンドを試していたのですが、明らかに動きがおかしなところがあり、少し調べてみました。 そして、「netstatコマンドの代替と思って安易にssコマンドを使うと、これは痛い目に遭うな……」ということが分かったので、不幸になる人を少なくするためにこのエントリを書きました。 概要 結論から先に言うと、CentOS 7/ RHEL 7のssコマンドには「UDPの開放ポートがTCPと報告される」というひどいバグがあり、使うべきではありません。 また、ssコマン
cpで大量のファイルをコピーした（4億3200万件、39TB）
GNUのcpを使って大量のファイルをコピーしたところ、cpの設計上の問題で、極めてコピーが遅かったというお話。 My experience with using cp to copy a lot of files (432 millions, 39 TB) よう。俺は最近、大量のファイルをコピーする必要があったんだが、UNIXは20年もやってきた俺の経験からも、cpの挙動には驚かされたし、俺の意見はコミュニティに共有されるべきだと思う。 環境：古いDellのサーバー（2コア、初期メモリ2GB、追加して10GB、Ubuntu Trusty）と、新しいDellのストレージ格納機(MD 1200)にある、12個の4TBディスクでRAID 6が設定してあって、全体で40TBの要領を持ち、二つのドライブが同時に失敗しても問題ない環境。サーバーは遠隔地バックアップに使われていて、ディスクへの書き込みし
Linuxでアウトバウンド帯域幅を制限する | DevelopersIO
はじめに オンプレとAWSにまたがるシステムの場合、オンプレ側の帯域を圧迫しないようサーバからの通信に帯域制限をかけたい場合があります。 今回はLinuxの機能を利用しアウトバウンド通信の帯域を制限してみました。 Windows Serverの帯域制限についてはこちらをご覧ください。 帯域制限が無い状態 制限が無い状態でのアウトバウンド速度を計測してみましょう。 5GBのファイルをS3にアップロードしてみます。 [ec2-user@ip-10-0-0-37 ~]$ mkdir files [ec2-user@ip-10-0-0-37 ~]$ dd if=/dev/zero of=files/5GB count=5120 bs=1M > /dev/null [ec2-user@ip-10-0-0-37 ~]$ aws s3 sync files s3://qos.test --region=
EXT4 vs XFS vs Btrfs vs ZFSをfioでベンチマークを取ってみました。 - Qiita
概要 CentOS7のデフォルトのファイルシステムがXFSとなりました。 mkfsコマンドでも、minix, xfs, btrfsが使えるようになりました。 そこで気になるファイルシステムを色々調べ、ベンチマークを自分なり取ってみました。 多少なりともご参考になればと思います。 色々なファイルシステム こちらをご参考ください。 http://qiita.com/sion_cojp/items/c8e015db39ddbf43012e それぞれファイルシステムを作ってみる 今回の環境は CentOS6（ホスト） 4Core, MEM:32G, HDD:300G CentOS7（ゲスト。こちらで計測しております。） vCPU *1, MEM:4G, HDD:40G 容量が少なかったため、btrfsのベンチマークが終わった後、zfsにファイルシステムを変更し検証をしております。 ### zfsの
fork()は失敗するんだぜ、覚えときな
fork() can fail: this is important あー、fork()のことね。プロセスがもっとプロセス作るためのやつな。いや、他にもプロセス作る方法はあるけどな。ま、面白い話がもうひとつあるから聞かせてやるよ。 forkは失敗するんだぜ。分かってるか？ マジで分かってるか？ マジだぜ。forkは失敗するもんだ。mallocと同じさ。失敗することもある。そんなに頻繁にってわけじゃないけどさ、でも失敗したら、無視できっこないぜ。ちっとは脳みそ働かせなきゃならん。 forkが0を返したら、そいつは子プロセスで、親なら正数を返すってことは、みんな知ってるよな。その値は子のpidだ。こいつを保存しといて、あとで使うってわけだ。 失敗を確認しない場合どうなるか知ってるか？ そうだよ。お前多分、"-1"（forkのエラー通知）をpidとして扱ってるんだろ。 さて、問題の始まりだ。本当
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記
誰でも知っていることだけど、LinuxというOSというかカーネルはLinus Torvaldsが学生のときに趣味で作ったのがはじまりだ。それは1991年ころの話で彼が21歳の頃だ。個人の趣味で作ったものが、いつの間にかに世界中のコンピュータだけでなく、携帯や家電や様々な機械の制御に使われている。 Linus Torvalds - Wikipedia 1994年ころには、PCで動く個人向けOSとしては十分な機能を持っていた。Xもあるし、gccなどのコンパイラもあるし、GNU Emacsやbashもあるので、ちょっとしたプログラムを作るには十分な機能を持っていた。 当時、勤め先のマシンはSunのワークステーションで仕事でLinuxを使う機会は全然なかったのだけど、自宅のPCにSlackwareのCDを入れてみたりした。日常的に使うことはなかったけど、1998年にOracleがLinux版を出し
「Systemd」を理解する ーシステム管理編ー | ギークを目指して
前回の記事「Systemd」を理解するーシステム起動編ーでは、Systemdの概念とSystemdによるLinux起動プロセスの内容を解説させていただいた。第二回となる今回の記事では、Systemdを利用したシステムの管理方法を記載していきたいと思う。 今回の記事ではSystemdのsystemctlコマンドを利用したサービス（プロセス）管理方法と、journalctlコマンドを利用したSystemd journalログ照会の2章立てでSystemdによるシステム管理を解説させていただく。また、各コマンドは先日リリースされたCentOS7上で動作確認させていただいた。 systemctlを利用してサービスを管理する Systemd環境にてサービス管理を行う場合、主にsystemctlコマンドを利用するが、一部、従来のコマンドも利用可能となっている。使途別のコマンドを見ていこう。 Unitの
Ctrl+Cとkill -SIGINTの違いからLinuxプロセスグループを理解する | ギークを目指して
しばらくLinuxネタが続く・・。 近いうちに最近出たJava8ネタを書いてみようと思います。が、もう少しLinuxネタにお付き合いください。 前回はsshdを対象に親プロセスをkillした場合の動作を確認した。 killされたプロセスの子プロセスは孤児プロセスとなり、カーネルによって自動的にinitプロセスの子として扱われる事を説明した。（この動作を「リペアレンティング」と呼ぶ） 今回はこの続き。 Linuxで作業していてCtrl+Cしてプロセスを終了した場合、フォアグラウンドのプロセスやその子プロセスも一緒に終了する。 ということは、子プロセスは孤児として扱われず、リペアレンティングされていないことになる。 今回の記事ではこの振る舞いの違い（リペアレンティングされるか否か）に着目し、kill -SIGINTコマンドとCtrl+Cの違いについて考えていく。 そもそもkillコマンドやCt
Hello, systemd
8. SIGKILLしたらどうなるか # systemctl status httpd httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: active (running) since Thu 2014-07-24 03:57:50 JST; 1min 21s ago Main PID: 1311 (httpd) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service ├─1311 /usr/sbin/httpd -DFOREGROUND ├─1451
UNIXドメインソケット通信の内容を見たい - Qiita
UNIX domain socket 通信は同一マシン上のプロセス間通信にしか使えないというデメリットがありますが，tcp 通信よりも圧倒的にパフォーマンスが良いので要求仕様的に使わなければならない局面は多いと思います 今回はフロントに Nginx で proxy して同一マシン上の別プロセスで動いているアプリケーションサーバーに対して UNIX domain socket 通信を行う構成で実際のアプリケーションサーバーに流れている通信を見たい時にどうするか書きます 実際にトラブルが起こった時に実際にどのような通信が流れているのかは tcp 通信なら tcpdump をすれば見れますが，UNIX domain socket 通信の場合は容易に見ることが出来ないので実際のアプリケーションサーバーにどのような通信が流れているのか分かりません しかしアプリケーションサーバーにどのような通信が流れ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Btrfsの基礎 part1 機能編
コマンドによる「負荷」の原因切り分け
Loading...