Fast Thread Locals In Rust
Fast Thread Locals In Rust Oct 3, 2020 Rust thread-locals are slower than they could be. This is because they violate zero-cost abstraction principle, specifically the “you don’t pay for what you don’t use” part. Rust’s thread-local implementation( 1, 2 ) comes with built-in support for laziness — thread locals are initialized on the first access. Sometimes this overhead is a big deal, as thread l
マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー
また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ
innodb_thread_concurrencyに関する話 | GREE Engineering
こんにちわ。せじまです。今回の話は軽く書こうと思っていたのですが、長くなりました。まぁInnoDBの話なのでしょうがないですね。 はじめ 今回はinnodb_thread_concurrencyについてお話しようと思います。できれば、事前にInnoDB の mutex の話（入門編）を読んでいただいた方が、より深く理解していただけるのではないかと思います。 長いので、最初に五行でまとめます 現代において、ほとんどのケースでは、innodb_thread_concurrencyはデフォルトの0のままで問題ないと思います。なぜなら、最近のInnoDBはかなり良くなってきたからです。 それでもinnodb_thread_concurrencyをチューニングするとしたら、「高負荷状態になったときでもスレッド間の公平性をなるべく担保し、安定稼働させるため」と割り切って使うのが良いでしょう。 inno
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.8.4 InnoDB のスレッド並列性の構成
InnoDB は、オペレーティングシステムスレッドを使用して、ユーザートランザクションからの要求を処理します。 (トランザクションは、コミットまたはロールバックする前に、InnoDB に多数の要求を発行する可能性があります。) コンテキストスイッチングが効率的な、マルチコアプロセッサを備えた最新のオペレーティングシステムおよびサーバーでは、並列スレッドの数を制限することなく、ほとんどのワークロードが適切に動作します。 スレッド間のコンテキストスイッチングを最小限に抑えることが役立つ状況では、InnoDB はいくつかの手法を使用して、並列実行中のオペレーティングシステムスレッドの数 (したがって、一度に処理される要求の数) を制限できます。 InnoDB がユーザーセッションからの新しい要求を受信したとき、並列実行中のスレッドの数が事前に定義された制限に達している場合、その新しい要求は再試行
MySQL5.6と5.7のちょっとした違いとinnodb_thread_concurrencyの影響 - hiroi10のブログ
この記事はMySQL Casual Advent Calendar 2016の22日目です。 innodb_thread_concurrencyを最近のデフォルトである0と論理CPUコア数の2倍の48に設定した場合に観測出来た小ネタです。ベンチマークのtpsを載せていますが、1回しか取得してないので、割と誤差があると考えられるため、目安程度に見てください。 環境 CentOS 6.6(2.6.32-504.12.2.el6.x86_64) Xeon E5-2643 v2 3.5GHz x 2(2P12C24T) Memory 64GB (8GB x 8, DDR3 1866MHz) HDD SAS 300GB x 2 10k rpm(RAID1 BBU付き) FileSystem ext4 ベンチマークのデータ量はinnodb_buffer_pool_sizeに収まる量 メモリで殴るような
Ruby の Timeout の仕組み - tmtms のメモ
Ruby で長い時間掛かるかも知れない処理のタイムアウトを行うにはこんな感じにします。 require 'timeout' begin Timeout.timeout(3) do # 3秒でタイムアウト hoge # 何かの処理 end rescue Timeout::Error puts 'なげーよ' # タイムアウト発生時の処理 end Timeout.timeout はブロック開始時にスレッドを作成し、そのスレッドで指定された秒数だけ sleep して、sleep から復帰してもまだブロックが終わってなければ作成元のスレッドに対して Timeout::Error 例外を発生させます。 指定時間以内に処理が終わる場合: timeout(X) │ スレッド作成 ─┐ │ │ ブロック実行 sleep X │ │ スレッドkill→ 🕱 │ timeout復帰 指定時間以内に処理が終わら
Ruby の Monitor と ConditionVariable の使い方 - Mame the hack
Ruby の Monitor と ConditionVariable の使い方 なかなかぐぐっても日本語の資料が見つからなかったので自分で動かしてみた。(ぐぐる能力低い) まずThreadの直列化 require "thread" require "monitor" moni = Monitor.new val = 0 Thread.new { 3.times { puts "thread1 start: #{val}" val+=1 sleep 0.1 puts "thread1 end: #{val}" } } Thread.new { 3.times { puts "thread2 start: #{val}" val+=1 sleep 0.1 puts "thread2 end: #{val}" } } sleep 結果は以下の通り。 start > end, start > en
RubyにおけるThreadとForkの速度比較 - while(true) ;
こんばんは、kazunyaaanです。今回は並列処理の速度比較を行います。 (個人的に専門が数値計算で、MPI等でごりごり並列化をおこなっているのでとてもわくわくです(笑)) 前回の記事で、RubyにおけるThreadは多くの場合にて "並行処理となる" ことに簡単にふれてみました。 今回は、Threadだけでなく、Forkも含めた、 Rubyでのマルチスレッドおよびマルチプロセスのプログラムとその速度比較を行ってみたいとおもいます。 まず実験環境 今回は贅沢に Intel Xeon E5-2690 v3 @ 2.60GHz (Turbo Boost時 3.5) 12Core × 1 DDR4 ECC 16GByte @ 2133MHz × 4 の計算機サーバを使って、CentOS7、Ruby 2.2.0 の実験環境を用意しました。 コード 今回は、 Normal : 普通に書いた場合 T
マルチスレッド/プロセスまとめ（Ruby編） - Qiita
プログラムの実行単位 固有のメモリ空間を持つ(リソースを共有しない) マルチプロセスの場合、物理/仮想メモリ領域間のアドレス解決のオーバーヘッドが高い。 プロセスの実行単位 共通のメモリ空間を持つ（リソースを共有する） マルチスレッドの場合、物理/仮想メモリ領域間のアドレス解決は発生しない。 ユーザースレッド ユーザー空間（アプリケーションが利用するメモリ空間）を利用 1つのプロセスに複数のスレッドがあっても、1つのスレッドしか実行されない。 OSカーネルを介さないスレッド切り替えのため、スレッド切り替えに伴うオーバーヘッドが少ない。 仮想VM上で実行されるスレッドをグリーンスレッドと呼ぶ。 カーネルスレッド カーネル空間（カーネルが利用するメモリ空間）を利用 1つのプロセスに複数のスレッドがある場合、同時に複数（CPUコア数分）のスレッドを実行できる。 OSカーネルを介するスレッド切り替
リクエスト単位でグローバルな参照を持たせてAuditログをスッキリ実装したい - Qiita
Rails等で毎日APIを納品している界隈の皆様方は、リクエスト毎にグローバルな変数を持ちたい時はたまにあるかと思います。例えば、ログを吐くためにRack::Requestオブジェクトをロガーから参照したいとか。モデルやサービス層である処理が呼ばれる毎にリクエスト者のAuditログを残したい場合などそうなりそうです。 class PostEditService def initialize(post, request) @post, @request = post, request end def call(new_body) @post.body = some_normalize(new_body) #... Rails.logger.info("[audit] ip: #{@request.ip}, ua: #{@request.user_agent}") end end サンプルのコ
Goでスレッド（goroutine）セーフなプログラムを書くために必ず注意しなければいけない点 - Qiita
Goは言語機能として並列実行をサポートしているけど、Goで書いたからといって自動的にデータ構造がスレッドセーフになるわけではないので、スレッド安全性を気にしなければならないはこれまでの言語と変わらない。どういうケースが良くてどういうケースがダメなのかを理解していないと安全なプログラムは書けない。それについて説明をしよう。 まず第一にEffective Goのこの一文は覚えておこう。 Do not communicate by sharing memory; instead, share memory by communicating. メモリを共有することで通信しようとしないこと。代わりに通信することでメモリを共有すること。 変数の値を変更したあとにチャネルなどを使わずに、おもむろに別のgoroutineからその変数の値を読み書きしてはいけない。そういうやり方だと読み書き操作の前後関係がき
並列に実行するんだけど並列度も制限したい時 - Qiita
まあ例を挙げて話したほうがわかりやすい気がするので例をあげると、たとえばあなたはオンプレミスからコンテナまで総計数千台のホスト的な何かで構成されたシステムを管理する必要があります、と。この規模になってくると当然日々何かが壊れては何かが直っていくのはそういうものですね。で、じゃあ、刻一刻と変わる管理台帳と実際の環境の整合性をチェックすることを考える、と。すると要件としては、 管理台帳から存在するはずのホスト名とそのIPアドレスの一覧を引っ張ってくる そこからまずホスト名をババババと名前解決して管理台帳どおりのIPアドレスが解決されるか確認する 次にそいつらが生きてると限らんので、解決されたIPアドレスに向かってICMP Echoパケットをババババと打ちまくって反応を見る ping応答あった「なにか」が、本当に管理台帳どおりのホストとは限らないので、とりあえずsshで入れるか確認する 入れたら
Rubyのスレッド周りの話 - Qiita
Rubyのスレッド周りを追ってみた。 最も効率が良いスレッドモデルは結論出ないんじゃないかと（物理的な環境、何を実装するか、性能以外の面でメンテナの問題とか）。 Ruby1.8系 「グリーンスレッド」 Ruby1.8ではOSではなくて仮想マシン(VM)上で実装されたマルチスレッドシステムを採用した。 これを「グリーンスレッド」という。カーネルでスレッドがサポートされていなくても動作する。 つまり、OSに依存せずにマルチスレッドを実現する。 メリット スレッドの起動、並列化の性能 Linux のネイティブスレッドの性能を上回る。つまり、ネイティブスレッドより低コストで起動、並列化を行える。 起動については、独自のアドレス空間を確保する必要がなく、わずかな量の仮想メモリを取得するだけ。 並列化については、カーネルレベルとユーザレベルの切り替えが必要ないことなど。 さまざまなOS間で移植が楽 デ
Queueを使ったワーカースレッド - うなの日記
Queueを使うとワーカースレッドが簡単に作れます。 ワーカースレッド(=仕事をするスレッド)は、キューから順番に仕事を取り出して実行するスレッドです。 これとは別に定期的に仕事を積むスレッドがいて、 ワーカースレッドは↑から仕事が積まれた場合にそれを取り出して実行します。 仕事がなければ、積まれるまで待つという動作をします。 ここで、キューへの仕事の追加と、キューからの仕事の取得は、別のスレッドで行われるため、同期制御が必要になります。 Queueを使うと、仕事を積む人とワーカースレッドの同期制御が内部で隠蔽されるため、外側での同期化なしにワーカースレッドを作ることができます。 QueueのAPIはpopとpushがあります。(他にもあるけど) Queue#popで要素を取り出します。このとき、queueが空の時、呼出元のスレッドは停止(ブロック)されます。 Queue#pushで要素を
Mutex - うなの日記
Thread間の処理の同期にはMutexを使います。 Mutex#synchronizeで Mutexのロックの獲得 ブロックの処理を実行。 ロックの解除 を行います。Javaのsynchronizedブロックと似た感じで使えます。 require 'thread' m = Mutex.new ts = [] 3.times { |j| ts << Thread.start { m.synchronize { # ブロック内の処理が同期実行される。 5.times { |i| puts "thread-" << j.to_s << " : " << i.to_s sleep rand * 0.1 } } } } ts.each {|t| t.join } 実行結果です。ブロック内の処理が同期実行されています。 thread-0 : 0 thread-0 : 1 thread-0 : 2 t
Rails 4 is thread safe by default [Rails 4 Countdown to 2013] | The Remarkable Labs Blog
This post is part of a series of 31 Rails 4 articles being released each day in December 2012. A big change to Rails 4 is that production applications will now be thread safe by default. This will have huge performance benefits for applications as they will be able to serve more than one request at a time. Thread Safe Code If you are running a production server which allows for concurrency, such a
Rubyで並列処理が簡単にできるgem parallel - 酒と泪とRubyとRailsと
require 'rubygems' require 'parallel' require 'open-uri' require 'digest/md5' urls = [ 'http://farm4.staticflickr.com/3052/3086132328_e2041be795.jpg', 'http://farm7.staticflickr.com/6053/6312937936_cebaf2feb9.jpg', 'http://farm1.staticflickr.com/54/131841577_0e67642c02.jpg', 'http://farm3.staticflickr.com/2293/2266151759_058e732577.jpg' ] Parallel.each(urls, in_threads: 2) {|url| puts "start downl
Rubyで簡単にワークパイルを実装 - Hello, world! - s21g
ワークパイル（Work pile）は、並列処理の為のアルゴリズムの一種です。 lucille 開発日記: マルチスレッド化: ワークパイル 簡単に云ってしまえば、ワークパイルはサーバ/クライアント機構と似たようなもので、ジョブを処理するスレッド部分ではマスタースレッドから仕事(ジョブ)を受け取って処理し、仕事がなくなるまでループするというものです。 いわゆる生産者消費者問題を解決する手法の一つですね。 ちょっとサンプルコードを見てもらったほうがはやいかも。 workpile.rb 1 require 'thread' 2 3 class Workpile 4 def initialize(num_workers) 5 @queue = Queue.new 6 @workers = ThreadGroup.new 7 8 # Spawn worker threads 9 num
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fix #1627: prepared statement pool can be corrupted by exception by abezzub · Pull Request #17607 · rails/rails