前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
Tweet お知らせ - 2018.02.22 Linux カーネルはメモリが枯渇した際の挙動を十分に考慮しておらず、メモリの枯渇が原因でLinux システムがハングアップしてしまうことがあるという問題があります。 この問題に当社ソリューション事業部 半田 哲夫が4年半取り組み続けた結果、メモリの枯渇時にハングアップしてしまう処理の多くが修正されました。現時点までの道のりは、以下の資料／動画でご覧いただけます。 資料：https://elinux.org/images/7/73/CELFJP-Jamboree63-handa-ja.pdf（社外サイト） 動画：https://youtu.be/ZznEyf1PN0Q（社外サイト）
他のプロセスを中断せずに、その出力をミラーリングして新しくパイプで繋ぐ、そんなことはできるのでしょうか。 straceやgdbといったコマンドは一体どういう仕組みで動いているのでしょうか。 ptraceシステムコールを使い、プロセスが呼ぶシステムコールを調べて出力を覗き見するコマンドを実装してみたいと思います。 ptraceシステムコール Linuxを触っていると、いかにプロセスを組み合わせるか、組み合わせる方法をどれだけ知っているかが重要になってきます。 パイプやリダイレクトを使ってプロセスの出力結果を制御したり、コードの中からコマンドを実行して、終了ステータスを取得したりします。 プロセスツリーやプロセスグループを理解し、シグナルやnohupコマンドを使ったりします。 プロセスの扱いに慣れると疑問に持つのがstraceやgdbの仕組みです。 プロセスの実行しているシステムコールを出力し
セキュリティ企業のQualysは6月19日、LinuxなどのUNIX系OSに存在するメモリ管理の脆弱（ぜいじゃく）性に関する詳細を公開した。同社はこの脆弱性を「Stack Clash」と命名。攻撃に利用されればメモリ破損を誘発され、任意のコードを実行される恐れもあると解説している。 Qualysによると、Stack Clashの脆弱性は、Linux、OpenBSD、NetBSD、FreeBSD、Solarisの各OSで影響が確認されており、他のOSも影響を受ける可能性がある。 Stack Clashという名称は、各プログラムがコンピュータ上で利用するスタックと呼ばれるメモリ領域に由来する。各プログラムが必要とするスタックメモリが増えると、この領域は自動的に増大するが、増大し過ぎて別のメモリ領域に過度に接近すると、異なるメモリ領域のスタックとの間で衝突あるいはクラッシュが起きて、脆弱性が発生
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Linux Advent Calendarをご覧の皆様、初めまして。Piroといいます。普段はJavaScriptやRubyでのソフトウェア開発やFirefoxの法人向け技術サポートなどをしつつ、日経Linux誌でシス管系女子という連載マンガを描かせて頂いております。 連載の方で書くには粒度の大きい話題だったので公開するのにいい場所はないかなあと思っていたらLinux Advent Calendarという名前を見かけて、まだ空きがあったので「これや！」と思って勇んでエントリーしたのですが、埋まってみると皆さん当たり前ですがカーネルの話中
「いますぐ実践! 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) [バックナンバーのトップへ
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Linuxの生みの親であり、Linuxカーネルを最初に開発したLinus Torvalds氏は、カーネルバージョン4.8のリリース最終段階になって混入した「間抜けな」バグに怒りをあらわにしている。 米国時間10月2日、Torvalds氏はLinuxカーネルのメーリングリストへの投稿で、Linuxカーネルバージョン4.8のリリースを発表した。その文面は、いくつかの「極めてささいな」問題が、8番目で最後となる4.8のリリース候補版（RC8）から持ち越されていることに触れた以外は穏やかなものだった。 カーネル4.8では、Microsoftの「Surface 3」デバイスのタッチスクリーンと、「Raspberry Pi 3」のSoCのサポートな
新しくサーバ立てた時やサーバ追加した時に，そのサーバが他のホストの特定のポートと疎通できるかどうかチェックする必要が出てくる時がある．ACLとかの兼ね合い． そういうのは本番の環境だと監視のシステム等に組み込まれていたり，あるいはserverspecとかで確認されていることが多いと思うのだけれど，その場で雑に確認したくなることがあると思う．そういう時はtelnetで繋いで，quitして，というのを繰り返していく感じになりがちなのだけれど，対象となるホストの数が多くなってくるとそういうことを手でやるのも大変になってくる……というわけでこれです． $ (sleep 0.1; echo quit) | telnet $HOST $PORT) こういう風にしておくとtelnetで繋いだ後にquitを発行するということを自動でやってくれる． とはいうものの，こうすると正しく繋げているかどうかを目視で
レビュー自動承認化と精度100%を目指して。いち早く生成AIの導入に踏み出した「ユーザーレビュー基盤」の取り組み
某所で話題に上がったので軽くまとめてみる 以下のようなテストプログラムを走らせてみる。nice値５とnice値１０のスレッドが ビジーループを何回回すことができるか競争するというプログラムである struct thread_param { int prio; long counter; }; #define barrier() __asm__ __volatile__("": : :"memory") void* loop(void* _param) { struct thread_param *param = _param; setpriority(PRIO_PROCESS, 0, param->prio); usleep(1000); for(;;) { param->counter++; barrier(); } return NULL; } int main() { pthread
また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ
ALSA使用時に、使用したいサウンドカードがデフォルトに設定されておらず、音声の再生や、alsamixierでのコントロールができないことがある。 この問題の解決法として、サウンドカードの読込み順を変更する方法をまとめる。 また、（設定ファイルの記述ミスで）同時再生ができなくなる問題が発生したため、その対策法もまとめる。 環境 ハードウェア ATI HD6450 (SAPPHIRE HD6450 512M DDR3 PCI-E HDMI/DVI-D/VGA, [AMD/ATI] Caicos HDMI Audio [Radeon HD 6400 Series]) TASCAM US-100 (Texas Instruments PCM2900B Audio CODEC) ソフトウェア Arch_Linux (x86_64, Kernel 3.14-1-1-ARCH) ALSA (k3.14
Important It is often found during an ALSA installation, that the kernel driver modules for soundcards have not been properly installed on the system. To check if one's system has working soundcard driver modules, run lsmod. If there are no modules with the prefix of snd_, consider properly installing the kernel driver module for the system's specific soundcard. A more detailed guide can be found
なぜ asoundrc？ なぜ asoundrc が必要なのでしょうか？ .asoundrc も asound.conf も ALSA が適切に動作するために必要なわけではありません。 多くのアプリケーションはそれらがなくても動作するでしょう。 それらは、ルーティングやサンプルレート変換のような特別な機能を alsa-lib レイヤを通して許可するために利用されます。 .asoundrc ファイル このファイルは、あなたにカード/デバイスのさらに先進的な制御を可能にしてくれます。 .asoundrc ファイルは、あなたのシステムで利用可能な様々なカードの定義から構成されます。 このファイルは alsa-lib の pcm プラグインにアクセスさせてくれます。 これらのおかげで、あなたのカードをこのファイルに結びつけたり、マルチチャンネルカードのマルチ i/o にアクセスできます。 .aso
Advanced Linux Sound Architecture (ALSA) は、サウンドカードのデバイスドライバを提供する Open Sound System (OSSv3) を置き換えるために開発された Linux カーネルコンポーネントです。デバイスドライバの他に、ALSA は、カーネルドライバと直接やりとりせずに高レベルの API を使ってドライバ機能を使いたいという開発者のために、ユーザ空間のライブラリも提供しています。 インストール ALSA はデフォルトの Arch カーネルにモジュールセットとして含まれているので、インストールは不要です。 起動時に自動で udev があなたのハードウェアを調べて、オーディオカード用の適切なカーネルモジュールをロードします。したがって、サウンドはすでに鳴らせるはずです。ただ、デフォルトでは全てのチャンネルはミュートにされています。チャンネ
Why asoundrc? What is it good for, why do I want one? Neither the user-side .asoundrc nor the asound.conf configuration files are required for ALSA to work properly. Most applications will work without them. These files are used to allow extra functionality, such as routing and sample-rate conversion, through the alsa-lib layer. The actual reason that most applications will work without these user
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
