Railsで動いている会社のサービスのメモリ使用量を半分ぐらいにまで削れたぜぃぇーぃ
メモリ超過エラーを見なくなったのは快挙。
@fine_l どうやったんだ…
@ponapalt GCの設定見直し、jemallocを使う、N+1問題の解消、不要なGem削除、プロセス数の見直し……あたり。一番最後のが効いてるんじゃないかな感。
@fine_l まあプロセス少なくすればいいよね…ってそれはわかっとんねん!って感じやな…。Gem削除は最初に食いつぶすメモリ量には効くだろうけど、要らない部分は仮想メモリに吐き出されてRSSの削減にはならなさげ。
@ponapalt 最終的には再起動するしかないというのがなんだかなー、と思う。
@fine_l ruby…というよりLL全般そんなもんやで。インフラエンジニアが見たらキレそうになるような超ウルトラ富豪プログラミング。
@ponapalt 他の会社はどうやってるのかと調べたらメモリ64GBとかあってあはーってなった。
@fine_l だって人件費がいちばん高いんやから、LL使ってメモリくっそ使って富豪プログラミングしたほうが安いやん。
@fine_l そういう意味でのLightweightでしょう?(なおインフラ屋的にはDeadweightとかTonsofweightとかまあそんなやつ)
…っていう結論になるんだと思うけれど。
@ponapalt まぁ、うん、そうね。高級言語しか書けない民としては何もいえないです、はい。
@fine_l 結局アプローチの違いだし、いまどきメモリケチるためにプログラミング作業自体に人件費かけるとかばかなの?っていうのが正しいので、本当の正解はどれかというと「メモリ超過エラーが出たら増設予算を申請する」が正解。
@fine_l なのでうちみたいな化石はほっといてLLで書きまくれば良いのだ。
@ponapalt でも、どこかで低級言語というかOS寄りの作業が発生するのよなー。
@fine_l フルスタックエンジニアなら仕方ない!ケーブル持ってフリーアクセスフロアを這いまわるところまでがおしごとだ!
@ponapalt マジで仕方ねえな、HAHAHA
@fine_l その時々に必要なスキルの有効無効を切り替えて、インフラエンジニアモードとプログラマーモード(あるいは経営者モードとかまで)を行き来して守備範囲をデカくするしかないね。
@ponapalt ほんとにねー。今は営業の策定しているプランに提案したりツッコミ入れたり、なんなりして守備範囲が少しずつ広がってる
@fine_l 守備範囲広がるのはいいんだけど、広がれば広がるほど全スキルセット有効のまま取り組むと理不尽さに潰されることになるので、「営業モードの時は技術詳細まで立ち入る機能を切る」とかそういううまく渡り歩くスキルが必要。
…なお私は全部常に有効なのでお客さんに対しても割としつこく物言いをつける不器用タイプなのでまずい。
@ponapalt そうなんだよなー、そこなんだよなー。実際に作る側の知見も求められる場面もあって、こまめなオンオフが必要なんだよなー……。
@fine_l なおUnmanaged C++を普段から書いてる身としては、Mastodonサーバを動かすだけで「ふざっけんなてめええええ」って感じが本音だけれど。