はてなブックマーク

Linux カーネルの挙動を変更する次の 4 つの方法について整理する。 名称 概要 設定変更を反映するタイミング カーネルコンフィグ コンパイル時の設定 再ビルド ブートパラメータ カーネル起動時の設定 再起動 モジュールパラメータ モジュールロード時の設定 モジュールの再ロード カーネルパラメータ カーネル起動時の設定 リアルタイム 検証環境 カーネルコンフィグ 現在の設定を確認する 設定可能なパラメータ 設定を変更する ソースコード上の扱い Kconfig の実装 ブートパラメータ 現在の設定を確認する 設定可能なパラメータ 設定を変更する 一時的に変更する 永続的に変更する 設定の優先度 ソースコード上の扱い __setup の使い方 __setup の実装(蛇足) core_param の使い方 core_param の実装(蛇足) モジュールパラメータ 現在の設定を確認する 設

taskset と cgroupは、あるプロセスが利用可能な CPU コアを制限できる技術。どんな違いがあるのかを調べた。なお、本記事の cgroup は cgroup v1 のこと。 taskset は sched_setaffinity システムコールを利用したコマンドラインツール。sched_setaffinity はユーザが実行したプロセスの CPU Affinity をユーザの権限で変えられる。プロセスからは CPU が存在するけど自発的に使わない状態。(≒このコアじゃないとヤダ！) cgroup は CPU/メモリなどのリソースを隔離するための仕組み。cgroup は設定権限をファイルのパーミッションで管理し、ユーザからの操作を禁止できる。プロセスからは CPU が存在しない状態。(≒このコアだけ使ってね) sched_setaffinity と cgroup はユーザへのイン

created と mounted どちらもVuejsが提供するライフサイクルフック。たいていのサンプルでは、このライフサイクルフックのどちらかでAPIアクセスをするが、どんな違いがあるんだろう。 created インスタンスの初期化が済んで props や computed にアクセスできる DOMにはアクセスできない mounted created + DOMにアクセスできる APIアクセスは created と mounted のどちらで行う？ APIアクセスはほとんどのライブラリで非同期に行われる。そのため、 created と mounted のどちらでAPIアクセスを開始しようが、レスポンスが返ってきた時点でコールバックが実行される。 上記を踏まえて、レスポンス完了後のコールバックの中で、 propsにデータを設定するだけの場合は、 created を使う DOMを構築してる間

目的 検証環境 PostgreSQLを起動する PostgreSQLに接続する ホストからアクセスする コンテナを利用してアクセスする パターン1 コンテナを利用してアクセスする パターン2 PostgreSQLコンテナの停止 PostgreSQLコンテナの再開 初期データを設定する PostgreSQLコンテナの削除 PostgreSQLコンテナを消すとDBデータはどうなる? DBデータを永続化する ロケール設定 日本語化する なぜユーザ名やパスワードが起動引数で変えられるのか？ PostgreSQLコンテナの構成を知る PostgreSQLの設定の変更 設定ファイルの編集 編集した設定ファイルの配置 設定をまとめる 関連記事 目的 この記事はDockerで開発環境用のPostgreSQLを用意することを目的にしています。運用レベルの考慮はしていません。 検証環境 $ cat /etc/

認定Kubernetes管理者 (CKA) に ほぼ満点 で合格しました。 スコアは 98% でした。これはつまり、 Kubernetes 完全に理解した(入門した) という事ですね？ この記事は 認定Kubernetes管理者(CKA) の概要と勉強方法を共有します。 認定Kubernetes管理者(CKA) とは Linux FoundationとCloud Native Computing Foundation（CNCF）によって作成された、 Kubernetes 管理者向けの資格です。ハンズオン形式のテストで、ブラウザに試験問題と試験用の CLI 環境が用意され、そこで実際にクラスタを操作して問題を解いていきます。実技試験です。(ちなみにデベロッパー向けには CKAD という資格が存在します。) 受験時の注意点については、Candidate Handbook や Frequentl

kube-proxy は各ノードで動作するネットワークプロキシ。Service の仕組みの一部(ClusterIP や NodePort など)を実現し、クラスタ内部または外部から Pod にアクセスできるように制御する。 参考 Kubernetes Components 参考 Kubernetes Service Service は 特定ラベルの Pod に対する仮想的なエンドポイント。Kubernetes では Pod がどのノードに配置されるかが不定(オートヒーリングやオートスケールのため)のため、サービスディスカバリの仕組みが必要になる。 Service のサービスディスカバリ機能は DNS ではなくてプロキシ方式になっている。Service に割り当てられた ClusterIP にアクセスすると、各 Pod にアクセスが分散される。そのため、Pod の IP アドレスを直接意識す

環境 Kubernetes 1.15 ]# kubectl version Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:13:54Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c3324

SPAの場合はformタグに任せてデータをサブミットすることは稀で、通常は自身で定義したハンドラを呼び出してAjax通信を行うことが多い。 課題 以下のように<button type="submit" @click="exec">を使ってボタン押下時のハンドラを実行するのは危ない。 <template> <form> <input type="text" placeholder="username" /> <input type="text" placeholder="password" /> <button type="submit" @click="exec">submit</button> </form> </template> <script> export default { name: 'HelloWorld', methods: { exec: function () { /

Spring WebFluxに関する、いまの理解を整理する。 Spring WebFlux 以前の問題点 Javaスレッドでコンテキストスイッチ？ Spring WebFluxで課題をどう解決するか？ Spring MVC と Spring WebFlux を比較する 検証環境 シナリオ 実装の違い Spring MVC Spring WebFlux 1000ms遅延するアプリケーション 負荷をかける準備をする 負荷をかける レスポンスタイムの違い Spring MVC Spring WebFlux 利用するスレッド数の違い Spring MVC Spring WebFlux スレッドの使い方の違い Spring MVC Spring WebFlux スレッドが利用するメモリ量の違い Spring MVC Spring WebFlux １スレッドごとに利用するメモリ量 結論 参考 もっと参

メモリ管理は、Linux カーネルのコアな機能です。この機能を理解することで、サーバの統計情報の意味がわかるようになったり、トラブル解析ができるようになります。 この記事では、Linux カーネルのメモリ管理について勉強したことを基礎からまとめます。 時間がない人は ここ と ここ だけ読んでらえればと思います。 プロセス編はこちら。 www.kimullaa.com ハードウェア寄りの話 ノイマン型アーキテクチャ ハードウェア構成 UMA NUMA DMA アドレスの種類 セグメント(補足) ページング Huge Page 4-level-paging(補足) プロセスごとのメモリ空間の切り替え(補足) ZONE メモリ上限 メモリ空間 メモリの利用方針 メモリの獲得 ゾーンアロケータ ページ回収 回収時の処理 File Backed な動作を確かめる Anonymous な動作を確かめ

Linux システムコールについて調べたことをまとめる。システムコールの仕組みを理解すると、 OS とアプリケーションがどのように連携して動いているのかを理解できるようになります。 システムコールは CPU に依存する処理が多いため、 x86_64 に絞ります。 検証環境 システムコールとは システムコールの利用方法 ABI 実行してみる リングプロテクション ユーザモード スタック システムコールの実装を確認する システムコールは遅い？ vdso システムコールとライブラリ システムコール ライブラリ関数 参考書籍 さいごに 検証環境 ]# cat /etc/redhat-release CentOS Linux release 8.0.1905 (Core) ]# uname -a Linux localhost.localdomain 4.18.0-80.11.2.el8_0.x86

記事の内容 以下のソースコードがコンパイル~実行されるまでに、何が行われるのかを理解する。 細かいオプションや処理の詳細は追わない。 #include <stdio.h> #define MESSAGE "hello world\n" int main(int argc, char *argv[]) { printf(MESSAGE); return 0; } 記事の内容 検証環境 処理の流れ プリプロセス includeヘッダの検索パス デバッグコードを埋め込むためのマクロ定義 定義済みマクロ 2重インクルード防止 コンパイル 最適化 デバッグシンボル アセンブル ELF形式 ELFへッダー セクションヘッダー プログラムヘッダー リンク リンカの検索パス 静的リンク 動的リンク 静的リンク/動的リンク の違い ちなみに ロード ローダの指定 ローダの検索パス スタートアップルーチン 互

これは Linux Advent Calendar 2019の 15 日目の記事です。procfs について勉強したことをまとめます。 検証環境 procfs とは 代表的なファイル システム全体 /proc/cpuinfo /proc/meminfo /proc/cmdline /proc/filesystems /proc/modules /proc/mounts /proc/uptime /proc/loadavg プロセスごと /proc/[pid]/comm /proc/[pid]/cmdline /proc/[pid]/cwd /proc/[pid]/environ /proc/[pid]/exe /proc/[pid]/fd/ /proc/[pid]/maps/ /proc/[pid]/root /proc/[pid]/stat /proc/[pid]/status ユーザ空

普段はアプリケーションレイヤの仕事をしているため、「データベースはデータを入れておくただの箱」という発想でした。が、さすがにこれはまずいだろう、と思いたち、勉強中です。 とくにデータベースが専門領域というわけではないので、間違いがあれば教えてください。 検証バージョン はじめに WAL には何を書くの？ WAL の書き込み 関連するプロセス bgwriter checkpointer wal writer リカバリ Full Page Writes 動作検証 WALの書き込みタイミング WAL の準備 COMMIT 発行時/ WAL writerの定期実行 WALバッファあふれ CHECKPOINT, VACUUM実行時 Dirtyページのディスク書き込みタイミング テーブルのファイル位置を確認する チェックポイント バックグラウンドライタの定期実行 共有バッファがあふれたとき リカバリ

この記事は Java Advent Calendar 2018 の 9 日目のエントリーです。 流行をとらえた話題が多いなか、10~15年前感のあるコンテンツです。化石です。 しかし化石とはいえ、よく使う技術ではあります。 ということで、何気なく使ってたけど改めて勉強し直しました。 検証バージョン 検証環境 JDBCとは データベースアクセスの流れ fetchSize 検証する SPI PreparedStatement 検証する SQLException 検証する ISOLATION_LEVEL JDBCコネクションプール AP視点のメリット 検証する JDBCコネクションプール(DB視点) 検証する workerプロセスごとにメモリをどれくらい使うのか PreparedStatementのキャッシュ 検証する サーバサイドステートメントキャッシュ 検証する リクエストの最適化 レスポン

この記事は 品川 Advent Calendar 2019 の5日目です。 OB 枠での参加です。いったいどこの某弊社なんでしょうか… 。 本記事は Eclipse で Java ライブラリのコードリーディングを行うときのコツをまとめます。あくまでも「自分はこんな考え方やテクニックを用いてコードを読んでいますよ」という内容なので、より良い方法があればコメントください。 検証環境 はじめに ソースコードのダウンロード コードを静的に読む 調査対象を明確にする 公式リファレンス Javadoc を読む 例外時に出るスタックトレース ログメッセージ パッケージやクラス名から推測する 実行してスタックを確認する 静的に読むときのテクニック クラスにジャンプ(Ctrl + Shift T) アウトラインの表示(Ctrl + o) クラス内の文字列検索(Ctrl + F) リッチな検索(Ctrl +

Linux カーネルのメモリ管理方法について、勉強したことをまとめる。プロセス編。 カーネル編はこちら。 www.kimullaa.com メモリ管理の特徴 連続したメモリ領域 プロセスごとに独立したアドレス空間 実行例 メモリの効率的な割り当て デマンドページング スワップ 2種類のメモリ種別 実行例(オーバーコミット) 実行例(スワップ) 実メモリ空間の共有 メモリの利用量 実行例(vssとrss) 実行例(pss) 実行例(uss) ちなみに メモリ空間 メモリレイアウト ASLR(Address Space Location Randomization) ELFファイル ヒープ ライブラリ スタック vsyscall, vdso (virtual dynamic shared object) コピーオンライト(CoW) KSM 参考 OS は CentOS7.6、カーネルは次のバー

検証環境 ファイルシステムとは何か? ファイルアクセスの詳細 ストレージデバイスの特徴 open inode dentry file dentry キャッシュと inode キャッシュの効果を測定する read ページキャッシュとバッファキャッシュ ページキャッシュ バッファキャッシュ direct I/O 先読み 汎用ブロック層 I/O スケジューラ write バッファリング ディスクへの書き込みタイミング 書き込みの同期 (参考) ファイルの削除 I/O の種別 参考 検証環境 ]# cat /etc/redhat-release CentOS Linux release 7.7.1908 (Core) ]# uname -a Linux localhost.localdomain 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon Sep 30 14:19:

ロードバランサとは DNSラウンドロビン DNSラウンドロビンでは対応できないこと L7ロードバランサ パケットの流れ L4ロードバランサ IPアドレス変換方式(NAT方式) パケットの流れ MACアドレス変換方式(DSR方式) パケットの流れ 構築してみる L7ロードバランサ 設定 パケットキャプチャ 接続元IPアドレスをバックエンドサーバに伝える IPアドレス変換方式(NAT方式) 設定 パケットキャプチャ MACアドレス変換方式(DSR方式) 設定 パケットキャプチャ 参考 ロードバランサとは ロードバランサは、複数のバックエンドサーバにリクエストを分散させるための仕組み。 DNSラウンドロビン 似たような負荷分散の仕組みとしてDNSラウンドロビンがある。 これはバックエンドサーバのIPアドレスをDNSレコードとして登録し、DNSの問い合わせ時にバックエンドサーバのIPアドレスを順番

課題 Vuejs利用時に、HTTPレスポンスの例外処理を共通化したい。 各画面の各リクエストごとに、例外処理を実装するのは避けたい。 解決方法 HTTPクライアントライブラリのAxiosの、interceptorsの仕組みを利用する。 検証環境 package.json "dependencies": { "axios": "^0.17.1", "vue": "^2.5.2", "vue-router": "^3.0.1", "vue-toasted": "^1.1.24" }, モックサーバを用意する 検証用に、エラーを返すモックサーバを用意する。 $ npm install -D json-server モック定義のファイル(mock.js)を用意する。 const jsonServer = require('json-server') const server = jsonServe

maxThreads リクエストを処理するスレッド数(workerスレッド)の上限 1リクエストを処理するために1workerスレッドを消費する コネクタ(HTTP1.1, AJPなど)ごとの上限 ただしスレッドプールをexecutorプロパティで指定した場合、この上限は無視される maxConnections 同時に受け付けるコネクション数の上限 workerスレッドに空きができるまで、リクエストは処理されない Nioコネクタなら maxThreads < maxConnections が可能 HTTP Keep Aliveごとにworkerスレッドを占有する必要がないから デフォルトは maxThreads=200, maxConnections=10000 詳細はブロッキングとかノンブロッキングを理解したい acceptCount 保留されている(Socket#accept()されな

docker-composeとは？ docker-composeは複数のコンテナを手軽に扱うためのツール。 yml形式でコンテナに関する設定ができ、 sample]$ ls docker-compose.yml docker-compose.yml version: "3" services: ap: image: "centos:7" command: ["tail","-f","/dev/null"] depends_on: - "db" db: image: 'centos:7' command: ["tail","-f","/dev/null"] up コマンドでコンテナが起動できる。 $ docker-compose up -d Creating network "sample_default" with the default driver Creating sample_db

2022-06-02 ファイルシステムのブロックサイズの活用事例 linux ファイルシステムのブロックサイズといえば、stat コマンドで表示されるこれ (IO Block: 4096 )。 どういうときにこの値がユーザ空間で利用されているかを調べた。 $ stat / File: ‘/’ Size: 270 Blocks: 0 IO Block: 4096 directory Device: ca01h/51713d I… 2022-02-20 RHEL8 系で Error: Specified qdisc not found. が出たときの対処方法 linux network RHEL8 系(Rocky でも CentOS Stream でも良いが)で netem を利用しようとしたら、Specified qdisc not found. が出た。 $ sudo tc qdisc a