L7: Performance Frans Kaashoek 6.033 Spring 2013.

Slides:



Advertisements
Similar presentations
IT253: Computer Organization
Advertisements

- Dr. Kalpakis CMSC Dr. Kalpakis 1 Outline In implementing DBMS we need to answer How should the system store and manage very large amounts of data?
1 Parallel Scientific Computing: Algorithms and Tools Lecture #2 APMA 2821A, Spring 2008 Instructors: George Em Karniadakis Leopold Grinberg.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Disks and RAID.
CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11: :30 AM.
CSE506: Operating Systems Disk Scheduling. CSE506: Operating Systems Key to Disk Performance Don’t access the disk – Whenever possible Cache contents.
Spring 2003CSE P5481 Introduction Why memory subsystem design is important CPU speeds increase 55% per year DRAM speeds increase 3% per year rate of increase.
CS CS 5150 Software Engineering Lecture 19 Performance.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 19 Performance of Computer Systems.
Lecture 17 I/O Optimization. Disk Organization Tracks: concentric rings around disk surface Sectors: arc of track, minimum unit of transfer Cylinder:
1 Chapter Seven Large and Fast: Exploiting Memory Hierarchy.
Disk Drivers May 10, 2000 Instructor: Gary Kimura.
CS 501: Software Engineering Fall 2000 Lecture 19 Performance of Computer Systems.
CS CS 5150 Software Engineering Lecture 25 Performance.
Disks.
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 22 Performance of Computer Systems.
1  2004 Morgan Kaufmann Publishers Chapter Seven.
Secondary Storage CSCI 444/544 Operating Systems Fall 2008.
Secondary Storage Management Hank Levy. 8/7/20152 Secondary Storage • Secondary Storage is usually: –anything outside of “primary memory” –storage that.
Introduction to Database Systems 1 The Storage Hierarchy and Magnetic Disks Storage Technology: Topic 1.
CS4432: Database Systems II Data Storage (Better Block Organization) 1.
Lecture 11: DMBS Internals
Topic: Disks – file system devices. Rotational Media Sector Track Cylinder Head Platter Arm Access time = seek time + rotational delay + transfer time.
IT 344: Operating Systems Winter 2010 Module 13 Secondary Storage Chia-Chi Teng CTB 265.
 Higher associativity means more complex hardware  But a highly-associative cache will also exhibit a lower miss rate —Each set has more blocks, so there’s.
Chapter 111 Chapter 11: Hardware (Slides by Hector Garcia-Molina,
Lecture 10 Memory Hierarchy and Cache Design Computer Architecture COE 501.
1 CS 501 Spring 2006 CS 501: Software Engineering Lecture 22 Performance of Computer Systems.
Disks and Storage Systems
Chapter Twelve Memory Organization
CSE332: Data Abstractions Lecture 8: Memory Hierarchy Tyler Robison Summer
1/14/2005Yan Huang - CSCI5330 Database Implementation – Storage and File Structure Storage and File Structure.
The Design and Implementation of Log-Structure File System M. Rosenblum and J. Ousterhout.
Programming for GCSE Topic 5.1: Memory and Storage T eaching L ondon C omputing William Marsh School of Electronic Engineering and Computer Science Queen.
CS 153 Design of Operating Systems Spring 2015 Lecture 21: File Systems.
Lecture 3 Page 1 CS 111 Online Disk Drives An especially important and complex form of I/O device Still the primary method of providing stable storage.
DMBS Internals I. What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the database concurrently.
12/18/20151 Operating Systems Design (CS 423) Elsa L Gunter 2112 SC, UIUC Based on slides by Roy Campbell, Sam.
Multilevel Caches Microprocessors are getting faster and including a small high speed cache on the same chip.
Review °We would like to have the capacity of disk at the speed of the processor: unfortunately this is not feasible. °So we create a memory hierarchy:
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 23 Performance of Computer Systems.
DMBS Internals I February 24 th, What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the.
DMBS Internals I. What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the database concurrently.
DMBS Architecture May 15 th, Generic Architecture Query compiler/optimizer Execution engine Index/record mgr. Buffer manager Storage manager storage.
CSE 451: Operating Systems Winter 2012 Secondary Storage Mark Zbikowski Gary Kimura.
Lecture Topics: 11/22 HW 7 File systems –block allocation Unix and NT –disk scheduling –file caches –RAID.
1 Lecture 16: Data Storage Wednesday, November 6, 2006.
Lecture 17 Raid. Device Protocol Variants Status checks: polling vs. interrupts Data: PIO vs. DMA Control: special instructions vs. memory-mapped I/O.
Storage Devices CS 161: Lecture 11 3/21/17.
Lecture 16: Data Storage Wednesday, November 6, 2006.
FileSystems.
Disks and RAID.
Basic Performance Parameters in Computer Architecture:
CS 554: Advanced Database System Notes 02: Hardware
Cache Memory Presentation I
File Processing : Storage Media
Lecture 11: DMBS Internals
Lecture 9: Data Storage and IO Models
File Processing : Storage Media
CSE 451: Operating Systems Winter 2007 Module 13 Secondary Storage
Secondary Storage Management Brian Bershad
Persistence: hard disk drive
CSE 451: Operating Systems Secondary Storage
Disks and Storage Systems
CSE 451: Operating Systems Winter 2009 Module 12 Secondary Storage
Secondary Storage Management Hank Levy
CSE451 File System Introduction and Disk Drivers Autumn 2002
Virtual Memory: Working Sets
CSE 451: Operating Systems Spring 2007 Module 11 Secondary Storage
CSE 332: Data Abstractions Memory Hierarchy
Presentation transcript:

L7: Performance Frans Kaashoek Spring 2013

Overview Technology fixes some performance problems –Ride the technology curves if you can Some performance requirements require thinking An increase in load may need redesign: –Batching –Caching –Scheduling –Concurrency Important numbers

Moore’s law “Cramming More Components Onto Integrated Circuits”, Electronics, April 1965 cost per transistor transistors per die

Transistors/die doubles every ~18 months

Moore’s law sets a clear goal Tremendous investment in technology Technology improvement is proportional to technology Example: processors Better processors  Better layout tools  Better processors Mathematically: d(technology)/dt ≈ technology  technology ≈ e t 5

CPU performance

DRAM density

Disk: Price per GByte drops at ~30-35% per year

Latency improves slowly Year # Improvement wrt year #1 Moore’s law (~70% per year) DRAM access latency (~7% per year) Speed of light (0% per year)

Performance and system design Improvements in technology can “fix” performance problems Some performance problems are intrinsic –E.g., design project 1 –Technology doesn’t fix it; you have think Handling increasing load can require re-design –Not every aspect of the system improves over time

Approach to performance problems Users complaint the system is too slow –Measure the system to find bottleneck –Relax the bottleneck Add hardware, change system design Client InternetServerDisk Client ….

Performance metrics Performance metrics: –Throughput: request/time for many requests –Latency: time / request for single request Latency = 1/throughput? –Often not; e.g., server may have two CPUs Server Client …

Heavily-loaded systems Once system busy, requests queue up users bottleneck Latency users Throughput

Approaches to finding bottleneck Measure utilization of each resource –CPU is 100% busy, disk is 20% busy –CPU is 50% busy, disk is 50% busy, alternating Model performance of your system –What performance do you expect? –Say net takes 10ms, CPU 50 ms, disk 10ms Guess, check, and iterate ClientNetworkServerDisk

Fixing a bottleneck Get faster hardware Fix application –Better algorithm, fewer features –6.033 cannot help you here General system techniques: –Batching –Caching –Concurrency –Scheduling

Case study: I/O bottleneck

Hitachi 7K400

Inside a disk 7200 rpm 8.3 ms per rotation

Top view 88,283 tracks per platter 576 to 1170 sectors per track

Performance of reading a sector Latency = seek + rotation + reading/writing: –Seek time: 1-15 ms avg 8.2msec for read, avg 9.2ms for write –Rotation time: ms –Read/writing bits: 35-62MB/s (inner to outer) Read(4KB): –Latency: 8.2msec+4.1msec+~0.1ms = 12.4ms –Throughput: 4KB/12.4 msec = 322 KB/s 99% of time spent moving disk; 1% reading!

Batching Batch into reads/writes into large sequential transfers (e.g., a track) Time for a track (1,000×512 bytes): –0.8 msec to seek to next track –8.3 msec to read track Throughput: 512KB/9.1 msec = 55MB/s As fast as LAN; less likely to be a bottleneck

System design implications If system reads/writes large files: –Lay them out contiguously on disk If system reads/writes many small files: –Group them together into a single track Modern Unix: put dir + inodes + data together

Caching Use DRAM to remember recently-read sectors –Most operating systems use much DRAM for caching –DRAM latency and throughput orders of magnitude better Challenge: what to cache? –DRAM is often much smaller than disk

Performance model Average time to read/write sector with cache: hit_time × hit_rate + miss_time × miss_rate –Example: 100 sectors, 90% hit 10 sectors Without cache: 10 ms for each sector With cache: 0ms * ms*0.1 = 1ms –Hit rate must be high to make cache work well!

Replacement policy Many caches have bounded size Goal: evict cache entry that’s unlikely to be used soon Approach: predict future behavior on past behavior Extend with hints from application

Least-Recently Used (LRU) policy If used recently, likely to be used again Easy to implement in software Works well for popular data (e.g., “/”)

Is LRU always the best policy? LRU fails for sequential access of file larger than cache –LRU would evict all useful data Better policy for this work load: –Most-recently Used (MRU)

When do caches work? 1.All data fits in cache 2.Access pattern has: –Temporal locality E.g., home directories of users currently logged in –Spatial locality E.g., all inodes in a directory (“ls –l”) Not all patterns have locality –E.g., reading large files

Simple server while (true) { wait for request data = read(name) response = compute(data) send response }

Caching often cannot help writes Writes often must to go disk for durability –After power failure, new data must be available Result: disk performance dominates write- intensive workloads Worst case: many random small writes –Mail server storing each message in a separate file Logging can help –Writing data to sequential log (see later in semester)

I/O concurrency motivation Simple server alternates between waiting for disk and computing: CPU: --- A B --- Disk: --- A B ---

Use several threads to overlap I/O Thread 1 works on A and Thread 2 works on B, keeping both CPU and disk busy: CPU: --- A B C --- …. Disk: --- A B --- … Other benefit: fast requests can get ahead of slow requests Downside: need locks, etc.!

Scheduling Suppose many threads issuing disk requests: 71, 10, 92, 45, 29 Naïve algorithm: random reads (8-15ms seek) Better: Shortest-seek first (1 ms seek): 10, 29, 45, 71, 92 High load -> smaller seeks -> higher throughput Downside: unfair, risk of starvation Elevator algorithm avoids starvation

Parallel hardware Use several disks to increase performance: –Many small requests: group files on disks Minimizes seeks –Many large requests: strip files across disks Increase throughout Use many computers: –Balance work across computers? –What if one computer fails? –How to program? MapReduce?

Solid State Disk (SSD) Faster storage technology than disk –Flash memory that exports disk interface –No moving parts OCZ Vertex 3: 256GB SSD –Sequential read: 400 MB/s –Sequential write: MB/s –Random 4KB read: 5700/s (23 MB/s) –Random 4KB write: 2200/s (9 MB/s)

SSDs and writes Writes performance is slower: –Flash can erase only large units (e.g, 512 KB) Writing a small block: 1.Read 512 KB 2.Update 4KB of 512 KB 3.Write 512 KB Controllers try to avoid this using logging

SSD versus Disk Disk: ~$100 for 2 TB –$0.05 per GB SSD: ~$300 for 256 GB –$1.00 per GB Many performance issues still the same: –Both SSD and Disks much slower than RAM –Avoid random small writes using batching

Important numbers Latency: – ms: instruction time (1 ns) – ms: DRAM load (100 ns) –0.1 ms: LAN network –10 ms: random disk I/O –25 ms: Internet east -> west coast Throughput: –10,000 MB/s: DRAM –1,000 MB/s: LAN (or100 MB/s) –100 MB/s: sequential disk (or 500 MB/s) –1 MB/s: random disk I/O

Summary Technology fixes some performance problems If performance problem is intrinsic: –Batching –Caching –Concurrency –Scheduling Important numbers