Re: [GENERAL] Runtime analysis
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] Runtime analysis |
Дата | |
Msg-id | 13785.1509896484@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [GENERAL] Runtime analysis (Neto pr <netoprbr9@gmail.com>) |
Список | pgsql-general |
Neto pr <netoprbr9@gmail.com> writes: > I expected that the first run would always take longer than the others > because of not having cached data, but look what happened: > - in 6 cases the first execution was more faster than all executions. > - in 2 cases only, the first exececution was more slower than all > executions > If anyone has any suspicion or explanation, why in some cases the first > execution can be faster than the others, please reply to this email. Your Xeon is probably a variable-speed chip; did you take measures to freeze the CPU frequency? On my RHEL server, I generally can't get very reproducible numbers from benchmarks unless I first do "sudo cpupower frequency-set --governor performance" because the default "ondemand" governor is too eager to ratchet down the frequency. Things might be different on Debian though. In multi-socket servers, NUMA effects across sockets can be a big headache too. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: