# 202005

## kicad
- [KiCadで雑に基板を作る チュートリアル](https://www.slideshare.net/soburi/kicad-53622272)
- [KiCad Pcbnew 各レイヤの役割 - uchan note](https://uchan.hateblo.jp/entry/2016/02/07/153224)

## 正規表現
- [Regulex：JavaScript Regular Expression Visualizer](https://jex.im/regulex/)
- [Regex Test Drive | 正規表現オンラインテストサイト](https://regex-testdrive.com/ja/)
- [Regexper](https://regexper.com/)
- [Online regex tester and debugger: PHP, PCRE, Python, Golang and JavaScript](https://regex101.com/)

## 過去の時点のファイルを見る
-  git blameして犯人探し
  - `$ git blame <file-path> | grep <sentence>` とか
- ただ見る
  - `$ git show <hash>:<abslute-file-path>`
-  詳細に見る
  - `$ git blame <hash> -- <file-path>`

## Route Explorer
- https://www.juniper.net/documentation/software/junosphere/junosphere2.0/help/Route-Explorer-Junosphere.pdf

## [RIPEstat](https://stat.ripe.net/)

## [SSD VPS Servers, Cloud Servers and Cloud Hosting by Vultr - Vultr.com](https://www.vultr.com/)

## [Hurricane Electric Internet Services - Internet Backbone and Colocation Provider](http://he.net/)

## vyosで拠点間ipsecがきれる
- [Vyos command "reset vpn ipsec-peer 10.15.20.69" is getting stuck - General questions - VyOS Platform Community Forums](https://forum.vyos.io/t/vyos-command-reset-vpn-ipsec-peer-10-15-20-69-is-getting-stuck/3383/7)
- [クラウドユーザーガイド（拠点間VPNゲートウェイ：IKEv1 L2TPv3/IPsec VPN（L2VPN）で接続する拠点側VPN装置の設定（VyOS）） | ニフクラ](https://pfs.nifcloud.com/guide/cp/vpngw/cn_l2_vyos.htm)
- [Vyatta VPN IPsec tunnel random dropouts - Server Fault](https://serverfault.com/questions/586399/vyatta-vpn-ipsec-tunnel-random-dropouts)
- [VyOSを使った拠点間通信（VPN） - Qiita](https://qiita.com/tsukasa1301/items/cbb78e6f29cb9b5e713b)

## passive matrix mixer
- [(6) ヘルミッペ on Twitter: "某氏 @Phasma のマトリックスミキサーを見て、欲しくなったので、作ってみることにした。こんな感じでいいだろうか。 https://t.co/vNbIDtujdO" / Twitter](https://twitter.com/komiya_ma/status/1147505752749199360)

## `logger(1)` コマンドはRFC5424で出す
- REF3164のフォーマットで出したい場合 `--rfc3164` の指定が必要
```
 logger -n localhost -P 10514 -t mytest -p user.notice --rfc3164 "TEST LOG"
 ```

## PCB CAD用ライブラリ
- [Free Online PCB CAD Library | Ultra Librarian](https://www.ultralibrarian.com/)
- [RS Component Search](https://rs.componentsearchengine.com/)
- [SamacSys Component Search](https://componentsearchengine.com/)

## [zabbix-agentがmemory leakしていたのでZabbix communityにBug patch/reportを出してみた話 - JP7FKFの備忘録](https://jp7fkf.hatenablog.jp/entry/20200520/1589984006)// ちなみのこのbugreportを出したのもmergeされたのももうしばらく前(2019年末から2020年頭)の話．

私は仕事でも趣味(?)でも，OSSの監視ツールである[Zabbix](https://www.zabbix.com/)に大変お世話になっている．
zabbixは主にネットワークやサーバなどのインフラに強みをもった監視ツールで，サーバならzabbix-agent, ネットワーク機器ならSNMPなどを主に用いて，各種ステータスやメトリクスの監視，可視化が行えるツールである．

先日このzabbixから一つのalertが飛んできた．アラート内容は `available memory` に関するアラート．これが何を意味するかと言うとつまり，空きメモリに余裕がないということである．
グラフ波形を見る限り日を追うごとにメモリが少しずつ侵食されており，典型的なメモリリークの症状であった．また身の回りの他の人からも同様の症状があるという報告を得た．
top/htop等を見てmemoryを専有するプロセスを探したところ `zabbix-agentd` と書かれたプロセスのメモリ使用率が著しく高いことがわかった．
ここまでで，何らかの原因でzabbix-agentdがmemory leakしていることがわかった．

zabbixがOSSであることを知っていたため，私は原因を突き止め，デバッグし，まず自分の身の回りで生じているメモリリークによる影響を排除しようと考えた．
また，まだreportが上がっていないのであればzabbixのOSS communityに対しbug patch/reportをあげ，自分自身が少しでも普段利用しているzabbixに貢献し，また同様のことで困っている方の助けに少しでもなれればうれしい，と考えた．
今回はその過程を少し記録しておく．

### Root Causeの特定
top等のコマンドを用いて特定できるのはあくまでどのプロセスがメモリを専有しているか，という情報のみである．
ここからzabbix-agentdがメモリを大きく専有していることまではわかったが，ここからやるべきことは `"zabbix-agentdのどこでこのメモリリークが生じているか"` を確かめることである．
メモリリークを検出する方法はたくさんの手法があるが，今回の場合実行ファイルがあるだけで利用できるという点にメリットを感じて [Valgrind](https://valgrind.org/) を用いた．
Valgrindの詳細な動作については，私は理解していないが，おそらくはサンドボックス上でバイナリを実行し，その実行時に特にメモリを取り扱うシステムコール等をwrapすることでリーク等を検知できる仕組みが備わっているのではないかと思う．

zabbix-agentdをValgrindを食わせて実行した結果，次のような結果が得られた(一部抜粋)．

```
==27583== HEAP SUMMARY:
==27583==     in use at exit: 109,825 bytes in 188 blocks
==27583==   total heap usage: 44,181 allocs, 43,993 frees, 4,111,671 bytes allocated
==27583==
==27583== 1 bytes in 1 blocks are definitely lost in loss record 1 of 38
==27583==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27583==    by 0x162F4D: zbx_malloc2 (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x168C40: zbx_strncpy_alloc (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x168EA4: zbx_strcpy_alloc (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x13F420: VFS_FILE_CONTENTS (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x12C91C: process (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x128C9C: ??? (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x12911E: listener_thread (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x14FF44: zbx_thread_start (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x11A597: MAIN_ZABBIX_ENTRY (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x1516A7: daemon_start (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x11A9FA: main (in /usr/sbin/zabbix_agentd.orig)
==27583==
==27583== 98,304 bytes in 1 blocks are definitely lost in loss record 38 of 38
==27583==    at 0x4C31D2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27583==    by 0x162FFC: zbx_realloc2 (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x168CC0: zbx_strncpy_alloc (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x168EA4: zbx_strcpy_alloc (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x13F420: VFS_FILE_CONTENTS (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x12C91C: process (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x128C9C: ??? (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x12911E: listener_thread (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x14FF44: zbx_thread_start (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x11A597: MAIN_ZABBIX_ENTRY (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x1516A7: daemon_start (in /usr/sbin/zabbix_agentd.orig)
==27583==    by 0x11A9FA: main (in /usr/sbin/zabbix_agentd.orig)
==27583==
==27583== LEAK SUMMARY:
==27583==    definitely lost: 98,305 bytes in 2 blocks
==27583==    indirectly lost: 0 bytes in 0 blocks
==27583==      possibly lost: 0 bytes in 0 blocks
==27583==    still reachable: 11,520 bytes in 186 blocks
==27583==         suppressed: 0 bytes in 0 blocks
==27583== Reachable blocks (those to which a pointer was found) are not shown.
==27583== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==27583==
==27583== For counts of detected and suppressed errors, rerun with: -v
==27583== Use --track-origins=yes to see where uninitialised values come from
==27583== ERROR SUMMARY: 592818 errors from 11 contexts (suppressed: 0 from 0)
```
`1 bytes in 1 blocks are definitely lost in loss record 1 of 38` などの出力がみられる．
これはこの部分でmemory leakがある(具体的にはメモリへのポインタを失う)ことを示している．
続けて，lostしたと考えられる箇所が記述されている．

上記に示した2件ではどうやら `zbx_strncpy_alloc()` 内部で利用されている`zbx_malloc2()`, `zbx_realloc2()`で生じているように見受けられる．
ここのコードを見てみる．
```
void    zbx_strncpy_alloc(char **str, size_t *alloc_len, size_t *offset, const char *src, size_t n)
{
        if (NULL == *str)
        {
                *alloc_len = n + 1;
                *offset = 0;
                *str = (char *)zbx_malloc(*str, *alloc_len);
        }
        else if (*offset + n >= *alloc_len)
        {
                while (*offset + n >= *alloc_len)
                        *alloc_len *= 2;
                *str = (char *)zbx_realloc(*str, *alloc_len);
        }

        while (0 != n && '\0' != *src)
        {
                (*str)[(*offset)++] = *src++;
                n--;
        }

        (*str)[*offset] = '\0';
}
```
ref: [zabbix/str.c at 4.4.5 · zabbix/zabbix · GitHub](https://github.com/zabbix/zabbix/blob/4.4.5/src/libs/zbxcommon/str.c)

内部で`zbx_malloc()`や`zbx_realloc()`がcallされていることがわかる．この定義を見ると
```
#define zbx_calloc(old, nmemb, size)  zbx_calloc2(__FILE__, __LINE__, old, nmemb, size)
#define zbx_malloc(old, size)   zbx_malloc2(__FILE__, __LINE__, old, size)
#define zbx_realloc(src, size)    zbx_realloc2(__FILE__, __LINE__, src, size)
#define zbx_strdup(old, str)    zbx_strdup2(__FILE__, __LINE__, old, str)
```
ref:[zabbix/common.h at b93f5c4fc09286ec199910c7d450b8a4bf4dd3de · zabbix/zabbix · GitHub](https://github.com/zabbix/zabbix/blob/b93f5c4fc09286ec199910c7d450b8a4bf4dd3de/include/common.h#L819)

`zbx_malloc2()`, `zbx_realloc2()`がcallされる．これらをみてみると．
```
void  *zbx_malloc2(const char *filename, int line, void *old, size_t size)
{
  int max_attempts;
  void  *ptr = NULL;

  /* old pointer must be NULL */
  if (NULL != old)
  {
    zabbix_log(LOG_LEVEL_CRIT, "[file:%s,line:%d] zbx_malloc: allocating already allocated memory. "
        "Please report this to Zabbix developers.",
        filename, line);
  }

  for (
    max_attempts = 10, size = MAX(size, 1);
    0 < max_attempts && NULL == ptr;
    ptr = malloc(size), max_attempts--
  );

  if (NULL != ptr)
    return ptr;

  zabbix_log(LOG_LEVEL_CRIT, "[file:%s,line:%d] zbx_malloc: out of memory. Requested " ZBX_FS_SIZE_T " bytes.",
      filename, line, (zbx_fs_size_t)size);

  exit(EXIT_FAILURE);
}
```
```
void  *zbx_realloc2(const char *filename, int line, void *old, size_t size)
{
  int max_attempts;
  void  *ptr = NULL;

  for (
    max_attempts = 10, size = MAX(size, 1);
    0 < max_attempts && NULL == ptr;
    ptr = realloc(old, size), max_attempts--
  );

  if (NULL != ptr)
    return ptr;

  zabbix_log(LOG_LEVEL_CRIT, "[file:%s,line:%d] zbx_realloc: out of memory. Requested " ZBX_FS_SIZE_T " bytes.",
      filename, line, (zbx_fs_size_t)size);

  exit(EXIT_FAILURE);
}
```
ref: [zabbix/misc.c at b93f5c4fc09286ec199910c7d450b8a4bf4dd3de · zabbix/zabbix · GitHub](https://github.com/zabbix/zabbix/blob/b93f5c4fc09286ec199910c7d450b8a4bf4dd3de/src/libs/zbxcommon/misc.c#L510)

このように書かれている．まずこの周辺の処理に問題がある可能性がある．

また，別の観点では，この`malloc()`や`realloc()`をcallする際，ポインタとsizeを引数として渡している事がわかる．
このポインタやsizeが不適切に設定されている可能性も考えられる．


結論から述べると，これはcallする側に問題があった．
debugをすすめていくと，Valgrindのリーク元として記載されている関数である[VFS_FILE_CONTENTS](https://github.com/zabbix/zabbix/blob/b93f5c4fc09286ec199910c7d450b8a4bf4dd3de/src/libs/zbxsysinfo/common/file.c#L148)のうち，[このzbx_readを用いた判定](https://github.com/zabbix/zabbix/blob/b93f5c4fc09286ec199910c7d450b8a4bf4dd3de/src/libs/zbxsysinfo/common/file.c#L211)がwhileループを抜けることなく不自然に繰り返されている事に気がついた．
本来であればこのロジックは`zbx_read()`でファイルディスクリプタからbufferに取り込み，utf8に文字コード変換をしcontentsとして保存するようなロジックであると考えられ，whileを複数回繰り返すことはあれど，`zbx_read()`からの戻り値が常に返却されることは考えにくい．
ここからたどっていき，`zbx_read()`が返却する`nbytes`が不適切に返却されている可能性が高いことがわかった．

```
int zbx_read(int fd, char *buf, size_t count, const char *encoding)
{
  size_t    i, szbyte, nbytes;
  const char  *cr, *lf;
  zbx_offset_t  offset;

  if ((zbx_offset_t)-1 == (offset = zbx_lseek(fd, 0, SEEK_CUR)))
    return -1;

  if (0 >= (nbytes = read(fd, buf, (unsigned int)count)))
    return (int)nbytes;

  find_cr_lf_szbyte(encoding, &cr, &lf, &szbyte);

  for (i = 0; i <= nbytes - szbyte; i += szbyte)
  {
    if (0 == memcmp(&buf[i], lf, szbyte)) /* LF (Unix) */
    {
      i += szbyte;
      break;
    }

    if (0 == memcmp(&buf[i], cr, szbyte)) /* CR (Mac) */
    {
      /* CR+LF (Windows) ? */
      if (i < nbytes - szbyte && 0 == memcmp(&buf[i + szbyte], lf, szbyte))
        i += szbyte;

      i += szbyte;
      break;
    }
  }

  if ((zbx_offset_t)-1 == zbx_lseek(fd, offset + (zbx_offset_t)i, SEEK_SET))
    return -1;

  return (int)i;
}
```
ref: [zabbix/file.c at b93f5c4fc09286ec199910c7d450b8a4bf4dd3de · zabbix/zabbix · GitHub](https://github.com/zabbix/zabbix/blob/b93f5c4fc09286ec199910c7d450b8a4bf4dd3de/src/libs/zbxcommon/file.c#L81)

このどこかで不適切なreturnが存在する可能性がある．
前述の通りwhileループを抜けることなく繰り返していることから，正の値の返却があり，可能性は2つに絞られる．
最後の
```
return (int)i;
```
もしくは10行目の
```
  if (0 >= (nbytes = read(fd, buf, (unsigned int)count)))
    return (int)nbytes;
```
である．

可能性としてかなり絞られたのでprintf debugしかり，logとして出力してdebugした．
```
int  zbx_read(int fd, char *buf, size_t count, const char *encoding)
{
  size_t          i, szbyte, nbytes;
  const char      *cr, *lf;
  zbx_offset_t    offset;

  if ((zbx_offset_t)-1 == (offset = zbx_lseek(fd, 0, SEEK_CUR)))
          return -1;

  if (0 >= (nbytes = read(fd, buf, (unsigned int)count)))
  {
          zabbix_log(LOG_LEVEL_CRIT, "zbx_read: read() returned: %d nbytes", (int)nbytes);
          return (int)nbytes;
  }

  find_cr_lf_szbyte(encoding, &cr, &lf, &szbyte);

  for (i = 0; i <= nbytes - szbyte; i += szbyte)
  {
          if (0 == memcmp(&buf[i], lf, szbyte))   /* LF (Unix) */
          {
                  i += szbyte;
                  break;
          }

          if (0 == memcmp(&buf[i], cr, szbyte))   /* CR (Mac) */
          {
                  /* CR+LF (Windows) ? */
                  if (i < nbytes - szbyte && 0 == memcmp(&buf[i + szbyte], lf, szbyte))
                          i += szbyte;

                  i += szbyte;
                  break;
          }
  }

  if ((zbx_offset_t)-1 == zbx_lseek(fd, offset + (zbx_offset_t)i, SEEK_SET))
          return -1;

  zabbix_log(LOG_LEVEL_CRIT, "zbx_read: zbx_read() returned: %d nbytes", i);
  return (int)i;
}
```
returnの直前にreturnとして返却する値をlogに表示した．
得られた結果はこうだ．
```
19207:20191202:093521.406 zbx_read: read() returned: -1 nbytes
19207:20191202:093521.406 zbx_read: zbx_read() returned: 66 nbytes
```
気づくべきなのは1行目．
```
  if (0 >= (nbytes = read(fd, buf, (unsigned int)count)))
  {
          zabbix_log(LOG_LEVEL_CRIT, "zbx_read: read() returned: %d nbytes", (int)nbytes);
          return (int)nbytes;
  }
```
というブロックに対して
```
19207:20191202:093521.406 zbx_read: read() returned: -1 nbytes
```
というログが出力されている．

意図としては`read()`からのreturn値が0以上である場合if内部を実行する．
具体的には`zabbix_log()`を実行し`(int)nbytes`をreturnするようなロジックを書きたいと考えられる．

しかしこのログ出力からは，return値が`-1`であるにも関わらずログに出力されている(if内部が実行されている)．
このことからキャストが不足している可能性があることに気づく．
軽率に
```
  if (0 >= (int)(nbytes = read(fd, buf, (unsigned int)count)))
  {
          zabbix_log(LOG_LEVEL_CRIT, "zbx_read: read() returned: %d nbytes", (int)nbytes);
          return (int)nbytes;
  }
```
とintキャストしてコンパイル，実行したところ，このメモリリークが解消された．
原因は`nbytes`が`size_t`として宣言されていたことにより`read()`のreturnが`-1`である場合でも正の値として判定されているところにあった．
これによりreturnされるべきでない`-1`という`read()`からの返り値が正の値としてint castされて返却されてしまい`VFS_FILE_CONTENTS()`におけるwhileでの異常なループが起きていたと考えられる．

上記の内容から原因は`zbx_read`内部における不適切な値返却だとわかった．

これらの内容をzabbix communityにbug patchとして報告した．
```eval_rst
.. image:: ../resources/images/202005_zab01.png
```

- [[ZBX-17036] fix: insufficient cast in zbx_read() and unstable statement - ZABBIX SUPPORT](https://support.zabbix.com/browse/ZBX-17036)

内容を読んだ人はわかると思うが，当初私はValgrindの出力から，`zbx_strncpy_alloc()` 内部で利用されている`zbx_malloc2()`, `zbx_realloc2()`に問題があるのではないかと信じ込み，不適切な報告をしてしまっている．
しかし対応していただいたレビューアには，「その部分は問題ないように見える」と優しく教えてもらった．
のちに手元で検証したところ，やはり問題はなく，自分のc言語に対する理解力の不足と思い込みがこのミスを招いている．

しかしそれとは別に私は上記のcast不足を提言し，改善したコードの提示をした．
そのコードはレビュアーによってより改善(具体的には`size_t`型(unsigned)として宣言されていた`nbytes`を`ssize_t`(signed)として定義するように変更)され，このメモリリークのbugは解消された．

- [...G...PS. [ZBX-17036] fixed memory leak and wrong type cast · zabbix/zabbix@faad83f · GitHub](https://github.com/zabbix/zabbix/commit/faad83f693fec3da8da4d632317df2094194aac4#diff-d4624555f86030495f87fa467a9d5d1a)

めでたしめでたし．
これによって私の身の回りのメモリリークは落ち着いた．よかった．

また，これをきっかけに[VFS_FILE_CONTENTS](https://github.com/zabbix/zabbix/blob/b93f5c4fc09286ec199910c7d450b8a4bf4dd3de/src/libs/zbxsysinfo/common/file.c#L148) 内で2箇所memory leakの危険性があることがわかり，ついでになおしてもらった．これに気づいたのはreviewerだったけど，この報告がきっかけになっていたのはうれしい．

P.S.
BugfixとしてChangelogに名前載せてくれた．ありがとう！
```eval_rst
.. image:: ../resources/images/202005_zab02.png
```

### まとめ
いつもお世話になってるzabbixに1nmくらいは貢献した気分．
OSSへの貢献ってなかなか技術力がない自分には難しいところがあるが，やれる部分でなんとか協力してやっていきたい．
また不適切な報告をしたのは大変申し訳ない事案であったので技術力をもうちょい高めていきたい．
「C言語ぜんぜんわかってなくてすまん」といったらありがたいお言葉をいただいた．気が休まる思い．ありがたい．
```eval_rst
.. image:: ../resources/images/202005_zab03.png
```

なんにせよリークが治って個人的には助かった．
英語でbugの議論したりするの，ちょっと楽しかった．まだまだだけど．
つい先日zabbix5.0がリリースされて，zabbix-agent2というgoで書かれた新しいagentも登場している．このcで書かれたagentがいつまで使われるのかわからないが，しばらくは使われる気もする．なんにせよ人に使われるものに1nmでも貢献できたことが嬉しい．
そういえばValgrindをつかってこうやってまともにメモリリークを調べたのも初めてのことだったっぽい．意外となんとかなるものだ．

### Special Thanks(Reviewer)!
- Glebs Ivanovskis
- Andris Mednis
- Martins Abele

### References
- [[ZBX-17036] fix: insufficient cast in zbx_read() and unstable statement - ZABBIX SUPPORT](https://support.zabbix.com/browse/ZBX-17036)
- [C/C++でのメモリリーク検出方法 〜AddressSanitizer, Valgrind, mtrace〜 - kivantium活動日記](https://kivantium.hateblo.jp/entry/2018/07/14/233027)

## [大規模環境向けパケット解析ツール「Moloch」を使ってみる | さくらのナレッジ](https://knowledge.sakura.ad.jp/18721/)
- [GitHub - aol/moloch: Moloch is an open source, large scale, full packet capturing, indexing, and database system.](https://github.com/aol/moloch)

## 人生楽しみたかったら，時には他人の視線を無視する勇気も必要なんだよ - 東京03

## kicad
- pcdかくときは2.54/1.27ベースでかいていくべき．細かくしすぎるとあとからアラインがむずい．

## ヘッドホンアンプの出力保護抵抗
- [メモ帳:ヘッドホンのインピーダンスカーブ - livedoor Blog（ブログ）](http://blog.livedoor.jp/r_ten/archives/51775445.html)

## [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html)

## [GitHub - earthly/earthly: Build automation for the container era](https://github.com/earthly/earthly)

## [IMI 情報共有基盤 コンポーネントツール](https://info.gbiz.go.jp/tools/imi_tools/index.html)

## [アルプスアルパインのエンコーダ](https://go.alpsalpine.jp/l/506151/2020-04-09/35nk5d)
- 機械式エンコーダについてよくまとまっている．

## ROE, ROA, EPS, PERとか
- ROE(Return On Equity, 自己(株主)資本利益率)
  - 10%が目安．(2018年東証一部平均9.8%)
  - ROE = EPS/BPS
        = 純利益/純資産(自己資本)
- ROA(Return On Asset, 総資産利益率)
  - 5%が目安
  - ROA = 純利益/総資産
- EPS(Earnings Per Share, 1株益)
  - 一株あたりの純利益
  - EPS = 純利益 / 発行済み株式数
- PER(Price Earnings Ratio, 株価収益率)
  - 純利益何年分の時価総額か．
  - PER = 株価 / EPS
        = 時価総額(発行済株式数 * 株価) / 純利益
  - 東証一部平均13倍．
  - 同一企業のPERの時系列変化や関連企業との傾向比較に有用．
  - 絶対値にそれほど意味はなく，変動や傾向を見る．微分するのがいいかも．
- BPS(Book-value Per Share, 1株当たり純資産)
  - 大きいほど安定している(純資産が多い)
  - BPS = 純資産 / 発行済み株式数
- PBR(Price Book-value Ratio, 株価純資産倍率)
  - 純資産の何倍の時価総額か．
  - 大きいと実際持っている資産より過大評価．
  - PBR = 株価 / BPS
        = 時価総額(発行済株式数 * 株価) / 純資産
  - 東証一部大型株:1.8, 中型: 1.3, 小型0.9くらい．
- 平均利回り
  - 東証一部平均で2.26%