cor*_*ard 12 sql postgresql ruby-on-rails heroku newrelic
我正在使用NewRelic向我的一个Rails应用程序发出一个非常长的请求,发现许多SQL查询看起来完全是外来的,占用了相当长的时间.我已经谷歌了,但我已经空手而归,不管我是否可以防止它们发生.
SELECT COUNT(*) FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind in (?, ?) AND c.relname = ? AND n.nspname = ANY (current_schemas(false))
Run Code Online (Sandbox Code Playgroud)
…和…
SELECT a.attname, format_type(a.atttypid, a.atttypmod), pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod FROM pg_attribute a LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum WHERE a.attrelid = ?::regclass AND a.attnum > ? AND NOT a.attisdropped ORDER BY a.attnum
Run Code Online (Sandbox Code Playgroud)
...每次发生7次,共计145ms和135ms.
SELECT DISTINCT(attr.attname) FROM pg_attribute attr INNER JOIN pg_depend dep ON attr.attrelid = dep.refobjid AND attr.attnum = dep.refobjsubid INNER JOIN pg_constraint cons ON attr.attrelid = cons.conrelid AND attr.attnum = cons.conkey[?] WHERE cons.contype = ? AND dep.refobjid = ?::regclass
Run Code Online (Sandbox Code Playgroud)
......以104毫秒的成本进行了2次,并且......
SHOW search_path
Run Code Online (Sandbox Code Playgroud)
...一次通话命令45ms.
我的直觉说这些与Postgres Rails适配器有关,但是我不明白是什么触发了它们或者它们正在做什么,或者(更重要的是)它们在典型请求中被解雇的原因.
我只是更彻底地检查了日志,看起来这个请求运行的Dyno在几秒钟前已经转换为"up",所以很可能这个请求是第一个.
小智 9
表pg_class,pg_attribute,pg_depend等都描述了postgres中的表,列和依赖项.在Rails中,模型类由表定义,因此Rails读取表和列以确定每个模型的属性.
在开发模式下,它会在每次访问模型时查找这些值,因此如果您最近发生了变化,Rails就会知道它.在生产模式下,Rails会缓存它,因此您可以更频繁地看到这些,因此它确实不是一个问题.
归档时间: |
|
查看次数: |
3270 次 |
最近记录: |