この記事は はてなエンジニア Advent Calendar 2022 16日目のエントリーです。 こんにちは、Webアプリケーションエンジニアの id:masawada です。過去のAdvent CalendarでLinuxデスクトップを業務利用している記事を書きまして*1、そこから早いもので3年経ちました。当初はこのころからの差分でも書こうかと考えていたのですが、書き出してみると案外大きな変化はなくネタとしてイマイチ面白みに欠けるので企画を練り直すことに。(裏返せば十分に安定して利用できているということで、それはそれでありがたいのですが!) 考えているうちに、そういえば社内でLinuxデスクトップを利用している他のエンジニアはどんな環境で作業しているのかな? と気になったのでアンケートをとってみることにしました。 アンケートの方法 以下の項目でGoogle Formを用意しました。 業
3. Shared LibrariesShared libraries are libraries that are loaded by programs when they start. When a shared library is installed properly, all programs that start afterwards automatically use the new shared library. It's actually much more flexible and sophisticated than this, because the approach used by Linux permits you to: update libraries and still support programs that want to use older, no
(This post is also available in English.) この記事は Linux memory management at scale を 著者の Chris Down さんの許可 を得て Hiroaki Nakamura が日本語に翻訳したものです。 原文のライセンス は CC BY-SA 4.0 であり、翻訳のライセンスも同じく CC BY 4.0 とします。 cgroup2 プロジェクトでの私の仕事の一部として Linux システムのリソース管理についてエンジニアと話すことに多くの時間をかけてきました。 これらの会話を通じてどんどん明らかになってきた 1 つの事実は多くのエンジニアは、シニア SRE たちでさえも、 Linux のメモリ管理についていくつかのよくある誤解を持っていて、そしてそれが彼らがサポートするサービスやシステムが本来確実に稼働したり効率的
日記的に。 ちょっと訳あって、14〜15年前のメーカー製PC (Windows XP 時代) の中身を見てディスクを抹消するべく、いつも持ち歩いている USB ブートできる Ubuntu を起動させようとしたら、なんとPCが古すぎて USB ブートしないw 仕方ないので、ディスクを取り外して別のPCで操作しようかと思ったのですが、正直、構造的に取り外しが面倒くさい感じ・・・。 USBブートに対応していない PC なので、DVDドライブからブートさせるべく、CD-R か DVD-R にブートできるイメージ焼き付けようかと思ったのですが、よく考えたら現代の Ubuntu をブートさせようとしても、スペックが足りなさそうで、まともに動かなそうだなと思いまして。 で、結論から書くとタイトルにある通り「linuxBean」という軽量な Ubuntu ベースのディストリビューションを使ってみたところ、
Linux kernel 3.9 のマージウィンドウでは SO_REUSEPORT というソケットオプションがマージされました。 Merge branch 'soreuseport' · c617f39 · torvalds/linux · GitHub これは同一ポートに複数のリスナー（listen ソケット）が bind できるようになるというもので、Webサーバなど単一のポートに多くのコネクションが来るようなワークロードで、複数プロセスでうまく負荷分散ができるようになるそうです。 （これまでだと一人がaccept()してそれぞれの worker に渡すというようなモデルがありましたが、これでは accept() する部分がボトルネックになってしまいがちでした。） BSDでは元々 SO_REUSEPORT オプションはあったようですが、マルチキャスト通信で使うもののようです。Linux
無償のIDS（侵入検知システム）「Snort」は、ネットワーク侵入検知および侵入防止ツールの中で長年の間、主導的な地位を保ってきた。オープンソースコミュニティーによる継続的な開発と親会社であるSourcefireに支えられ、今後もその地位は揺るがないだろう。（Sourcefireは何年もの間、ベンダーサポートと即時アップデート込みで、フル機能を搭載した商用版のSnortを販売してきた。機能が限定された無償版の提供も続けている）。 ただ、市場がSnortの独占状態にあるとはいえ、同様の機能を持つツールを無償提供するベンダーは他にもある。そうしたIDSプロバイダーの多くは、例えばSnortと他のオープンソースソフトウェアなど複数のエンジンを組み合わせ、無償の安定したIDSを構築している。以下では5つのフリーツールを紹介する。 IDS／IPSの関連記事 VMware vShieldより高性能？
はじめに こんにちは、技術顧問のsatです。 サイボウズでは、ファイルシステムサイズ拡張時にデータベースアクセスがスローダウンするという問題に長年悩まされてきました。本記事では運用本部の藤田と深谷がこの問題を解決した流れについて報告いたします。問題を解決するために2人はLinuxカーネルを修正しました。修正は社内に閉じたものではなく、執筆当時の最新 Linuxカーネルであるv4.17にマージされています。 問題 以下の操作の後にデータベースへのアクセスが一時的にスローダウンする ブロックデバイスのサイズを拡張する 上記デバイス上にあるファイルシステムのサイズを拡張する 原因 linuxカーネルはブロックデバイスのサイズ変更(縮小および拡張)時に、当該デバイス上にあるファイルシステムのページキャッシュ(後述)を無効化する*1 解決方法 ブロックデバイスのサイズ拡張時にはページキャッシュを無効
Mackerelチームのエンジニアのid:itchynyです。 「mackerel-agentを入れるとloadavgが7時間ごとに上昇する」 先日、このような問い合わせを複数のお客さまから受けました。私も実験してみたところ、確かに再現しました。EC2 t2.microにmackerel-agentを入れて簡単なログ監視とプロセス監視を設定し、数日放置しました。 確かに、約7時間ごとにloadavgが上昇しています。この周期のcronの設定はしておらず、またmackerel-agent内部でも7時間ごとに行う処理はありません。しかし、プラグインを多く入れるほどloadavgのピーク値も上がります。 本エントリーでは、この現象の原因について説明します。 loadavgが上昇する原因を調べるには、まずloadavg自体がどう計算されているかを知る必要があります。 まずは、Linuxがloada
Linuxを採用、Microsoftが発表した「Azure Sphere」とは：チップ、OS、クラウドで構成 Microsoftは2018年4月16日（米国時間）、セキュリティ確保を目的とした新IoTソリューション、「Azure Sphere」を発表した。チップ、LinuxベースのセキュアOS、Microsoft Azureによるサービスの三位一体で構成される。Linuxを採用している点が注目される。 Microsoftは2018年4月16日（米国時間）、セキュリティ確保を目的とした新IoTソリューション、「Azure Sphere」を発表した。これはチップ、LinuxベースのセキュアOS、Microsoft Azureによるサービスの三位一体で構成される大掛かりなもの。Linuxを採用している点が注目される。同社は既に、家電や社会インフラ機器など、多様な機器ベンダーに採用を働きかけている
Using Intel.com Search You can easily search the entire Intel.com site in several ways. Brand Name: Core i9 Document Number: 123456 Code Name: Emerald Rapids Special Operators: “Ice Lake”, Ice AND Lake, Ice OR Lake, Ice* Quick Links You can also try the quick links below to see results for most popular searches. Product Information Support Drivers & Software
図1 O（1）スケジューラの仕組み。プロセスが登録されているアクティブ・キューの中で最も高い優先度のキューの先頭から，実行するプロセスを選択します。 カーネル2.6で実装されたプロセス・スケジューラ（プロセスの実行順序を決めるための仕組み）です。 Linuxでは，同時に実行しなければならないプロセスを「アクティブ・キュー」に登録します。そして，登録したプロセスの中から，優先度の高い順に実行します。 カーネル2.4では，アクティブ・キューを1つしか持たず，すべてのプロセスをそのキューに登録していました。そのため，最も優先度の高いプロセスを見つけ出すにはキュー内をすべて調べなければならず，キュー内にプロセスが数多く存在すれば，それだけ処理時間が多くかかります。結果として，プロセスの実行速度が遅くなるわけです。 カーネル2.6では，優先度によって分けられたアクティブ・キューを複数持ちます。プロセ
自分自身の好みに合うLinuxを作ることは，決して難しくない。フリーソフトを手順よく組み合わせていくことで，ごく普通のユーザーであっても自分だけのLinuxを作成できる。本講座を読みながら，Linuxの仕組みを理解して『自分Linux』を完成させよう。 今回は，前回までに作成した各種ライブラリやコマンド群，カーネルを用いて，自分Linuxの起動開始部分までを組み立てる（図1）。この組み立て作業で重要なのは，PCの電源を投入してLinuxシステムが起動するまでの仕組み作りである。この仕組み作りは少々複雑だが，手順だけでなく，作業内容を理解しながら行えば，決して難しくはない。 それではまず，仕組み作りの予備知識として，Linuxシステムが起動するまでの流れを解説していこう。 電源オンから Linuxが起動するまで 最初にPCのハードウエアが起動するまでの流れを考えてみよう。PCの起動プロセスを
さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基本的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分
「PCをWin7のままにしておきたいのに強制的にWin10にするMSが嫌だ！Linuxに行く！」という方へLinuxユーザーとして言っておきたいこと
「PCをWin7のままにしておきたいのに強制的にWin10にするMSが嫌だ！Macに行く！」という方へMacユーザーとして言っておきたいこと という記事を見かけたので、Linuxデスクトップユーザーからも一言だけ言っておく。 結論から。 「悪いことは言わないからやめておけ！」 以前、いますぐWindowsを捨ててデスクトップでGNU/Linuxを使う10+の理由というエントリを書いたことがあるので、使っちゃいけないみたいなことを書くと、「おいおい、いまさら何言ってんだよ」と思われる方も居るかも知れない。だが、以前のエントリの主旨は「GNUのWindows移植版であるCygwinを使うぐらいだったらGNU/Linuxはいかが？」という提案をするためのものであり、いわばCygwinを使うようなIT技術者向けのメッセージである。Cygwinが必要だということは、UNIXライクなツール群を必要とす
RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね（ｷﾘｯ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした
ブートローダからカーネルまで これまでの私の ブログ投稿 を読まれた方はご存じかと思いますが、しばらく前から低水準言語を使うようになりました。Linux用x86_64アセンブリ言語プログラミングについても書いています。また、同時にLinuxのソースコードにも触れるようになりました。下層がどのように機能しているのか、コンピュータでプログラムがどのように実行されるのか、どのようにメモリに配置されるのか、カーネルがどのように処理や記憶をするのか、下層でネットワークスタックがどのように動くのかなどなど、多くのことを理解しようと意欲が湧いています。これをきっかけに、 x86_64 版Linuxカーネルについてシリーズを書いてみようと思いました。 私はプロのカーネルプログラマではないことと、仕事でもカーネルのコードを書いていないことをご了承ください。個人的な趣味です。私は下層で何が起きているのかとても
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Solutions Library | Amazon Web Services | AWS
