はてなブックマーク

Linux カーネルのメモリ管理方法について、勉強したことをまとめる。 メモリ管理はハードウェアに強く依存するため、x86_64 かつ OS起動後に 64bitプロテクトモード に移行したあとに話を絞る。また、OS は CentOS7.6、カーネルは次のバージョンを利用する。 ]# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) ]# uname -a Linux localhost.localdomain 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux 概要 ノイマン型アーキテクチャ コンピュータの基本的な構成のひとつ。次の図が参考になる。 ほぼ全てのコンピュータが、このアーキ

普段はアプリケーションレイヤの仕事をしているため、「データベースはデータを入れておくただの箱」という発想でした。が、さすがにこれはまずいだろう、と思いたち、勉強中です。 とくにデータベースが専門領域というわけではないので、間違いがあれば教えてください。 検証バージョン PostgreSQL 10.5 自前ビルド はじめに PostgeSQL におけるデータの実態はファイル。 言うまでもないが、ディスクに書きこむことでデータを永続化する。 しかし、メモリと比較してディスクへの読み書きは非常に遅い。 参考 プログラマーが知っておくべき「PC内部の通信速度」 そのため、ディスクアクセスをできる限り減らして、より高速にアクセスできるメモリで処理しておき、ある程度まとめてディスクに書き出せば早いじゃないか。(No Force = コミット 時にディスクへ書き込まない。いつか誰かがやる。) しかしこの

記事の内容 以下のソースコードがコンパイル~実行されるまでに、何が行われるのかを理解する。 細かいオプションや処理の詳細は追わない。 #include <stdio.h> #define MESSAGE "hello world\n" int main(int argc, char *argv[]) { printf(MESSAGE); return 0; } ]$ uname -rm 3.10.0-957.10.1.el7.x86_64 x86_64 ]$ gcc --version gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions

課題 SpringSecurityのサンプルでは、以下のようにROLEに基づいて認可していることが多い。 @Override protected void configure(HttpSecurity httpSecurity) throws Exception { httpSecurity.authorizeRequests() .antMatchers("/admin/**").hasRole("ADMIN") が、ロールに基づいた認可ではなく権限に基づいた認可を行いたい。つまり、ロールごとに複数の権限を持たせ、ユーザにロールを複数割り当てたい。 参考 業務システムにおけるロールベースアクセス制御 解決方法 SpringSecurityでは、AuthenticationクラスをもとにアクセスコントロールするためのEL式が提供されている。 ログイン時にAuthenticationクラスの

... "dependencies": { "vue": "^2.5.2", "vue-router": "^3.0.1" }, ... <template> <div> <h1>{{ msg }}</h1> <button type="button" @click="change">change</button> </div> </template> <script> export default { name: 'App', data () { return { msg: 'hello world' } }, methods: { change: function () { this.msg = 'good bye' } } } </script> <style scoped> div { text-align:center; } </style> これをブラウザで表示すると、 {{

ロードバランサとは ロードバランサは、複数のバックエンドサーバがあるときに、リクエストを分散させるための仕組み。 DNSラウンドロビン 似たような負荷分散の仕組みとしてDNSラウンドロビンがある。 これはバックエンドサーバのIPアドレスをDNSレコードとして登録し、DNSの問い合わせ時にバックエンドサーバのIPアドレスを順番に返事することで負荷分散する。 DNSラウンドロビンでは対応できないこと DNSの問い合わせ結果はクライアント側でキャッシュされるため 負荷が偏る可能性がある サーバダウンした時に、即座に切り替えられないクライアントがいる パーシステンス機能がない(クライアントごとに同一のサーバに割り振れない) 上記に対応したいときに、ロードバランサが使われる。 L7レベルでロードバランシングする クライアントから見たときの接続先IPアドレスはLBのIPアドレスになる バックエンドサー

version: "3" services: ap: image: "centos:7" command: ["tail","-f","/dev/null"] depends_on: - "db" db: image: 'centos:7' command: ["tail","-f","/dev/null"] $ docker-compose up -d Creating network "sample_default" with the default driver Creating sample_db_1 ... done Creating sample_ap_1 ... done $ docker-compose ps Name Command State Ports ----------------------------------------------- sample_ap_

先月の Spring Festで『Micrometer/Prometheusによる大規模システムモニタリング 〜ヤフーインターネット広告システムでの導入事例〜』というセッションを聴講し、興味を持ったので調べました。 Micrometerは、Spring Boot Actuatorが内部で利用しているライブラリです。 参考 Spring Boot 2.0 Release Notes Micrometer 対象バージョン Spring Boot 2.1.0.RELEASE Micrometer Core 1.1.0 Micrometerとは? モニタリングシステムに依存せずに、メトリクスの取得を透過的に行う仕組み。 以下の機能を提供する。 メトリクスの収集 モニタリングシステムへの通知 メトリスクの収集(micrometer-core)とモニタリングシステムへの通知(micrometer-re

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 () { /

はじめに 突然ですが、皆さんはアプリケーションで扱うBLOBデータをどこに保存しているでしょうか？大きく分けると、以下のいずれかになると思います。 ファイルストレージ データベース オブジェクトストレージ いずれも一長一短ありますが『SQLアンチパターン』という書籍では、データベースに格納することも検討せよ、としています。 では、データベースで管理するメリットとデメリットは何でしょうか。 メリット RDBMSのトランザクション内で操作が完結する(データだけ消えた、ファイルだけ消えたという不整合な状態にならない) データと同時にファイルのバックアップも取得できる バックアップ復元時にファイルも戻せる デメリット バックアップのサイズや取得時間が増加する バックアップの復元時間が増加する リソースを圧迫する ちなみに『SQLアンチパターン』には、オブジェクトストレージに関する記述はなかったと記

vue-tables-2とは vue-tables-2は、Vuejsでテーブルを表示するためのライブラリ。 良い点 ソート/検索/ページングをクライアント側だけで実施することができる サーバ側の実装はデータを全件返すだけのシンプルなAPIで済む 注意点 全データをクライアント側で保持する必要がある(データ量がクライアント側で保持できるサイズかどうかを事前に確認して適用すべき) サンプルコードについて サンプルコードはすべてJSFiddleに書いています。ソースコードはリンク先を参照してください。2018/5/9時点のmasterを直接参照しているので、急に動かなくなる可能性があります。 表示してみる まずは、単純にデータを表示してみる。 https://jsfiddle.net/kimulla/9LLqhxut/19/ 実装のポイント :columnsで、表示するデータのフィールド名を指定

docker-compose.ymlで利用できる変数と、Dockerコンテナで利用できる変数の2種類がある。 検証環境 $ docker -v Docker version 18.03.1-ce, build 9ee9f40 $ docker-compose -v docker-compose version 1.21.2, build a133471

リアルタイムなwebアプリを実現する方法(ポーリング、Comet、Server Sent Events、WebSocket) リアルタイムなwebアプリを実現する方法について、サンプルコードを作成しながら検証する。 注意点 この記事で記載している実現方法はいずれもHTTPレベルの仕組みで実現されるものであり、サンプルコードはあくまで実装例です。 サンプルコードは動作を確認するのが目的であり、プロダクション適用レベルの考慮は一切していません。 実現方法の一覧 ポーリング 画面をフルでレンダリングするパターン AjaxでJSONやXMLでデータを取得するパターン Comet(ロングポーリング) Server Sent Events WebSocket 詳細の理解は、以下の資料を参考にしてください。 参考 サーバPUSHざっくりまとめ サンプルコード ポーリング(Ajax) リアルタイム性はポー

この記事は、Spring WebFluxの前提である、ブロッキングやノンブロッキンクとは何か、Servlet3.0の Async Servletや Servlet3.1の NonblockingI/Oとは何か、を理解することが目的です。 検証バージョン > java -version java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) > ver Microsoft Windows [Version 10.0.17134.165] @Slf4j public class BlockingAndSingleEchoServer implements EchoS

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

$ docker run --name my-db -p 5432:5432 -e POSTGRES_USER=dev -e POSTGRES_PASSWORD=secret -d postgres:9.6 オプション 役割 --name my-db コンテナ名 -p 5432:5432 ホストのポート:コンテナのポート -e POSTGRES_USER スーパユーザ名(省略時は"postgres") -e POSTGRES_PASSWORD スーパユーザのパスワード(省略時はパスワードなしでログイン可) -e POSTGRES_DB データベース名(省略時はPOSTGRES_USERと同じ)デフォルトだとユーザ名と同じデータベースが存在しないとエラーになるため、変える機会は少なそう -e PGDATA PostgreSQLのデータの格納先ディレクトリ(省略時は/var/lib/postg

const jsonServer = require('json-server') const server = jsonServer.create() const middlewares = jsonServer.defaults() server.use(middlewares) server.listen(3000, () => { console.log('JSON Server is running') }) server.get('/unauthorized', (req, res) => { res.status(401).jsonp({ message: "unauthorized" }) }) server.get('/systemerror', (req, res) => { res.status(500).jsonp({ message: "something wro

Spring WebFluxに関する、いまの理解を整理する。 Spring WebFlux 以前の問題点 Tomcatは1リクエスト処理するのに1スレッドを割り当てる。リクエストが終わるまでスレッドは解放されないため、処理にブロッキングな部分があったとしてもスレッドを占有し続ける。 ネットワークI/O、外部サービス呼び出し、DBアクセスなどが典型的なブロッキング箇所で、例えば、低速なネットワークからのリクエストをひとたびreadすると、のんきにスレッドを占有してリクエストの到着を待つことになる。 このとき、同時に多くのリクエストを捌くためには多くのスレッドが必要になる。 参考: ブロッキングとかノンブロッキングを理解したい ただしスレッド生成には(少なくともスレッドごとに確保するスタック領域分の)メモリが必要。 参考: Javaはどのように動くのか～図解でわかるJVMの仕組み 参考: [調