タグ

ブックマーク / gihyo.jp (15)

  • 第38回 Linuxカーネルのコンテナ機能 ― cgroupの改良版cgroup v2 [2] | gihyo.jp

    前回の記事は、私が所属する会社のAdvent Calendarの5日目の記事でした。これまでは、この連載記事でAdvent Calendarに参加するのは1回だけでした。 今年はcgroup v2の話題を書こうと決めたときに、内容から考えて1回では済まない量になるだろうと思いました。そこで、続けて2回でcgroup v2の紹介をして、2つのAdvent Calendarに参加しようと決めました。1回目はちょうど社内で募集が始まっていた会社のAdvent Calendar、2回目は例年どおりLinux Advent Calendarに参加することにしました。 そういうわけで、今回の記事は昨年まで何度か参加していたLinux Advent Calendar 2017の19日目の記事です。 今回は、実際にcgroup v2を操作しながら、前回紹介したcgroup v2の特徴をおさらいしましょう。

    第38回 Linuxカーネルのコンテナ機能 ― cgroupの改良版cgroup v2 [2] | gihyo.jp
  • 第37回 Linuxカーネルのコンテナ機能 ― cgroupの改良版cgroup v2[1] | gihyo.jp

    この連載をはじめてから、毎年この連載の記事でAdvent Calendarに参加してきました。昨年までは、この連載の記事で"Linux Advent Calendar"に参加してきました。 今年は参加するカレンダーを少し変えて、まずはこの記事で私が所属する会社のAdvent Calendarであるファーストサーバ Advent Calendar 2017の5日目に参加してみます。あまりたくさんの人が興味を持たなさそうな話題なので、会社のAdvent Calendarにマッチするのか心配です (^_^;)。 さて、Linuxでコンテナでリソース制限を行うための機能として、この連載では第3回から第5回まで3回に渡ってcgroupについて解説しました。 cgroupは、多くのLinuxディストリビューションでinitとして採用されているsystemdが使っていますので、今やLinuxをお使いであ

    第37回 Linuxカーネルのコンテナ機能 ― cgroupの改良版cgroup v2[1] | gihyo.jp
  • 第24回 GTIDを使用したレプリケーション構成を作成する[1] | gihyo.jp

    従来のMySQLのレプリケーションでは、新規にスレーブを追加する際にマスターのバイナリログファイル名とバイナリログファイルのポジションを指定する必要がありました。 MySQL 5.6.5から追加された機能であるグローバルトランザクション識別子(GTID)を使用することで、マスターのバイナリログファイル名とバイナリログファイルのポジションを指定することなく、容易にレプリケーションを構成・開始できるようになります。今回はGTIDを使用したレプリケーション構成について紹介いたします。 環境構築 第22回 特定のSQL文が原因で発生したレプリケーション遅延の調査方法で紹介した方法にて、MySQLのインストールまで環境構築します。今回のMySQLのバージョンはMySQL5.6.31です。 構成は以下のようになっています。 GTIDを使用したレプリケーションの設定 MySQL5.6にてGTIDを有効に

    第24回 GTIDを使用したレプリケーション構成を作成する[1] | gihyo.jp
  • 第25回 MySQLの公式Dockerイメージのご紹介、PostgreSQL9.6.4とPostgreSQL10ベータ3リリース | gihyo.jp

    OSSデータベース取り取り時報 第25回MySQLの公式Dockerイメージのご紹介、PostgreSQL9.6.4とPostgreSQL10ベータ3リリース MySQLの公式Dockerイメージをご紹介します。PostgreSQLセキュリティアップデートであるPostgreSQL9.6.4と、次期メジャーリリースに向けたPostgreSQL 10ベータ3がリリースされました。 [MySQL]2017年8月の主な出来事 7月にコミュニティ版の現行製品はほぼ全ての製品でマイナーリリースが行われたため、8月はPython用接続部品Connector/Python 2.1.7と.Net用のConnector/Net 6.10.3リリース候補版(RC)のみのリリースとなりました。なおConnector/Net 6.10はEntity Framework (⁠EF⁠)⁠ Core 1.1対応を主眼

    第25回 MySQLの公式Dockerイメージのご紹介、PostgreSQL9.6.4とPostgreSQL10ベータ3リリース | gihyo.jp
  • C/C++プログラマのためのDTrace入門 記事一覧 | gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    C/C++プログラマのためのDTrace入門 記事一覧 | gihyo.jp
    tom__bo
    tom__bo 2016/10/19
  • 第7回 HotSpot JVMではどのようにオブジェクトが移動するのか | gihyo.jp

    1回目のマイナーGCまでの流れを把握する 前回は、HotSpot JVM(以下HotSpot)のヒープ構造を解説しました。今回は、HotSpot JVMの4つのヒープ領域がどのように使用されていくのかを見ていきましょう。 まず、アプリケーションがオブジェクトを作成すると、HotSpotはそのオブジェクトにEden領域を割り当てます。 図1 オブジェクトが生成されるとEden領域が割り当てられる アプリケーションが処理を実行していくと、オブジェクトがどんどん作成されていきます。その結果、Eden領域が次々と使用されていきます。 Eden領域がいっぱいになり、空き領域がなくなると、HotSpotはNew領域を対象にGCを行います。このGCは「マイナーGC」と呼ばれ、世代別GCで言う「若い世代のGC」になります。 このように、Eden領域で短命なオブジェクトを回収することで、ヒープを再利用できる

    第7回 HotSpot JVMではどのようにオブジェクトが移動するのか | gihyo.jp
  • 第4回 テーブルをコピーするついでにデータディレクトリーの中身を知る | gihyo.jp

    勉強用のMySQLをいじっている時に、「⁠もとに戻せない操作しちゃったけど戻せない……」ということはありませんか? MySQLのDDL(DROP TABLEやALTER TABLEなどの、定義を変更するためのステートメントのことです)はトランザクション非対応なので、一度DROPしてしまうとロールバックすることはできません。それどころか、DDLが実行される直前に「暗黙のコミット」が走る作りになっているので、トランザクションの最中にDDLを実行してしまうと、そこまでの操作はコミットされてしまうのです。そしてデフォルトでオートコミット……うっかりの種はどこにでも転がっています。 今回は、「⁠勉強用のMySQLのテーブルをコピーしてバックアップする」「⁠ついでにデータディレクトリーの構造を勉強する」がテーマです。 デモンストレーション環境について 今回利用している環境は、第2回 MySQLにはじめ

    第4回 テーブルをコピーするついでにデータディレクトリーの中身を知る | gihyo.jp
  • 第8回 MySQLのレプリケーション構成 | gihyo.jp

    第8回はMySQLの代表的なスケールアウト構成であるレプリケーション機能について解説します。 レプリケーションとは データベースでのレプリケーションは、多くの場合データを複数のサーバで保持することで、処理性能の拡張性や耐障害性の向上を狙いとしています。レプリケーションによってデータの複製が作成されることにより、1台のサーバに障害が発生した場合でもデータを失うリスクが削減できるほか、システムを継続利用できる可能性が高まります。さらに複数のサーバにデータが複製されている場合は、データ参照処理を分散できる利点があります。 MySQLサーバのレプリケーション機能は2000年5月にリリースされたMySQL 3.23.15から実装されており、MySQLサーバの中でも初期から含まれている機能の一つとなっています。 参考URL C.3.46 Changes in Release 3.23.15 (08 M

    第8回 MySQLのレプリケーション構成 | gihyo.jp
  • 第8回 データ処理における並列アルゴリズム[3] | gihyo.jp

    はじめに 前回は、結合処理の並列化における基戦略について説明し、ソートマージ結合における具体的な並列アルゴリズムを説明しました。今回は、ImpalaやPrestoに加えて、Apache SparkやHadoop MapReduceのMap Joinにおいても用いられているハッシュ結合における具体的な並列アルゴリズムを説明します。 ハッシュ結合における並列アルゴリズム ハッシュ結合は、2つのデータにおいて同一の属性値をもつレコードを見つける方法として、レコードのハッシュ値を用いるものです[1]⁠。すなわち、当該方法においては、一方のデータのすべてのレコードの結合キーに対してハッシュ関数を用いてハッシュ値を計算し、当該ハッシュ値からなるハッシュ表を事前に構築しておき、他方のデータのレコードの結合キーに対して同一のハッシュ関数から得られたハッシュ値を用いてハッシュ表を参照することにより、同一の

    第8回 データ処理における並列アルゴリズム[3] | gihyo.jp
  • 第1回 MySQLにおける開発の歴史と最新動向 | gihyo.jp

    連載では、現在MySQLを利用していて、チューニングやより大規模な環境に向けた構成の拡張を体系的に説明することを目的としています。MySQLのこれまでの開発と最新の動向から、チューニングやスケールアップ/スケールアウトの注意点を解説します。 第1回である今回は、MySQLのアーキテクチャをこれまでの開発の歴史と併せて解説します。 黎明期 MySQLの最初期のバージョンは1994年に開発され、1995年に公開されています。公開当初は独自のライセンスを採用していましたが、2000年にGPL v2を採用し、商用ライセンスとのデュアルライセンスモデルを採用しました。また、MySQLの代表的な機能の1つでもあるレプリケーションも2000年に実装されており、Webシステムとの相性の良さや構成の柔軟さから数多くのWebシステムで以前からMySQLが採用される理由にもなっています。 2001年にGA(G

    第1回 MySQLにおける開発の歴史と最新動向 | gihyo.jp
  • サイバーエージェントを支える技術者たち 記事一覧 | gihyo.jp

    第67回人事採用担当者に訊く!! エンジニアの育成に向けたサイバーエージェントの取り組みとは 編集部 2015-02-18

    サイバーエージェントを支える技術者たち 記事一覧 | gihyo.jp
  • 第5回 データ処理の並列化 | gihyo.jp

    はじめに 前回は、データ処理の方法を整理し、また、宣言型言語をインターフェースとして用いる並列データベースなどのデータ処理系を詳細に見ていく準備として、当該データ処理系における実行プランの作成の流れをかんたんに説明しました。今回は、当該データ処理系において、どのように実行プランを並列化するかについて、その概要を説明します。 データ処理における並列性について 並列データベースをはじめとするデータ処理系は、SQL文などの問い合わせ(クエリ)の内容に応じてデータ処理を行うものであり、問い合わせの観点においては、当該処理系において用いられる並列性(Parallelism)は、次の2つに分類することができます。 問い合わせ間の並列性(Inter-Query Parallelism) 問い合わせ内の並列性(Intra-Query Parallelism) 問い合わせ間の並列性は、複数の異なる問い合わせ

    第5回 データ処理の並列化 | gihyo.jp
  • 第2回 並列データ処理系の歴史と重要性 | gihyo.jp

    はじめに 前回は、連載の目的や、連載で扱う並列データ処理の定義について説明しました。今回は、並列データ処理系の歴史や重要性について見ていきます。技術を学ぶうえで、その技術歴史や重要性について理解しておくことはとても良いことですので、かんたんな読み物を読むつもりでお付き合いください。 並列データ処理系の進展 並列データ処理系における基的なアルゴリズムや処理方式は、並列データベースと称される並列化された[1]データベースシステムにおける技術に基づいています。 並列データベースに関する研究・開発は、1970年代からの並列データベースマシン(Parallel Database Machine)[⁠1、2、3]と称されるデータベース処理専用の並列計算機に遡ることができます。並列データベースマシンは、データ処理用途にカスタマイズされたプロセッサや記憶装置を用いていたため、必ずしも価格に見合った

    第2回 並列データ処理系の歴史と重要性 | gihyo.jp
    tom__bo
    tom__bo 2015/04/15
  • 第2章 関数プログラミングのパラダイム―命令プログラミングと何が違うのか | gihyo.jp

    この章では、命令プログラミングと関数プログラミングのパラダイムの違いを理解するために、簡単な計算問題を取り上げます。 命令プログラミングと関数プログラミング 当たり前過ぎて意識されていないかもしれませんが、改めて命令プログラミングのパラダイム(以下「命令型」と略記)を説明すると、次のようになります。 命令を列挙する(典型的には命令である文をセミコロンで区切って並べる) 状態がある(状態とは再代入可能な変数のこと) 再代入を使って状態を変化させる 一方、関数プログラミングのパラダイム(以下「関数型」と略記)は次のようになります。 関数を引数に適用する 状態はない (値を破壊したくなったら)新たな値を作る 状態がないので、変数の値は変わりません。これが関数プログラミングを永続データプログラミングと定義した理由です。しかし、関数型で当に問題が解けるのか疑問だと思います。これから簡単な計算問題を

    第2章 関数プログラミングのパラダイム―命令プログラミングと何が違うのか | gihyo.jp
    tom__bo
    tom__bo 2015/03/03
    関数型やらないとダメらしいしやるならHaskellやるべきらしい
  • エンジニアの学び方─効率的に知識を得て、成果に結び付ける 記事一覧 | gihyo.jp

    第4章何を学ぶか、何を作るか―問題の探し方と成果の出し方 西尾泰和 2014-07-25

    エンジニアの学び方─効率的に知識を得て、成果に結び付ける 記事一覧 | gihyo.jp
    tom__bo
    tom__bo 2014/08/04
  • 1