Высоко ждите в SAR
Можно всегда скрывать блоки позади приложения виртуализации (фронтэнд HTTP, FTP один, или что-то пользовательское). Но это означает, что необходимо было бы записать ЦП, вероятно, на экземпляре EC2, для отображения этих запросов и байтов копии в/из тех блоках S3.
Представление блока S3 непосредственно пользователю должно было бы следовать за правилами безопасности S3:
Как я могу управлять доступом к своим данным, хранившим на Amazon S3?
Клиенты могут использовать три механизма для управления доступом к ресурсам Amazon S3: политики блока, Списки управления доступом (ACLs) и аутентификация строки запроса. С политиками блока компании могут определить правила, которые применяются широко через все запросы к их ресурсам Amazon S3, таким как предоставление полномочий записи к подмножеству ресурсов Amazon S3. Клиенты могут также ограничить доступ на основе аспекта запроса, такого как ссылающийся домен HTTP и IP-адрес. С ACLs клиенты могут дать определенные разрешения (т.е. Чтение, ЗАПИШИТЕ, FULL_CONTROL) определенным пользователям для отдельного блока или объекта. С аутентификацией строки запроса клиенты могут создать URL к объекту Amazon S3, который только доступен на ограниченный срок.
svctm is a measure of how long the storage took to respond after the command left the IO scheduler and the IO was no longer under the kernel's control. You're seeing less than 1ms here which is excellent.
await is a measure of how long a given IO spent in the entire IO scheduler. You're seeing hundreds of milliseconds here which is pretty bad. Different people/vendors have different ideas about what is "good", I'd say under 50ms is good.
If your physical storage was slow, you'd see a large svctm and a large await. If the kernel's IO is slow, you'll see a large await but small svctm.
What IO scheduler are you using to this device? Given the small IO size (8kb) you care more about latency of requests than about bulk throughput. You'd probably be best off using the deadline scheduler, as opposed to the default cfq scheduler.
This is done by putting elevator=deadline on the kernel line in grub.conf and rebooting.
Also, given that you have hundreds of IOs backed up in the queue (avgqu-sz), and you're getting into thousands of IOPS (tps), and I'd assume that these are database IO which is likely to be directio so they cannot be merged into larger requests or take advantage of the pagecache, you may just be expecting too much from the storage subsystem.
Almost (:-))
await is a combination of service time and wait time (latency), where you are really concerned about wait time. If your service time is on the order of 10 milliseconds, things are getting slow when the wait is as big as the service time.
10 ms is a good service time for a Sun disk array: I don't know what is a good time for your disk, but I sorta suspect you're seeing an I/O bottleneck.
--davecb@spamcop.net
Судя по комментарию superjami, похоже, что у вас есть узкое место «над» диском / массивом. Я бы поинтересовался у сообщества postgres, что они рекомендуют в отношении планирования. В те дни, когда я работал в Solaris, мы использовали бы таблицу планировщика "cray" для машины, которая в основном была ядром базы данных ...
- dave