7 research outputs found

    ๋ฐ์ดํ„ฐ ์ง‘์•ฝ์  ์‘์šฉ์˜ ํšจ์œจ์ ์ธ ์‹œ์Šคํ…œ ์ž์› ํ™œ์šฉ์„ ์œ„ํ•œ ๋ฉ”๋ชจ๋ฆฌ ์„œ๋ธŒ์‹œ์Šคํ…œ ์ตœ์ ํ™”

    Get PDF
    ํ•™์œ„๋…ผ๋ฌธ (๋ฐ•์‚ฌ) -- ์„œ์šธ๋Œ€ํ•™๊ต ๋Œ€ํ•™์› : ๊ณต๊ณผ๋Œ€ํ•™ ์ „๊ธฐยท์ปดํ“จํ„ฐ๊ณตํ•™๋ถ€, 2020. 8. ์—ผํ—Œ์˜.With explosive data growth, data-intensive applications, such as relational database and key-value storage, have been increasingly popular in a variety of domains in recent years. To meet the growing performance demands of data-intensive applications, it is crucial to efficiently and fully utilize memory resources for the best possible performance. However, general-purpose operating systems (OSs) are designed to provide system resources to applications running on a system in a fair manner at system-level. A single application may find it difficult to fully exploit the systems best performance due to this system-level fairness. For performance reasons, many data-intensive applications implement their own mechanisms that OSs already provide, under the assumption that they know better about the data than OSs. They can be greedily optimized for performance but this may result in inefficient use of system resources. In this dissertation, we claim that simple OS support with minor application modifications can yield even higher application performance without sacrificing system-level resource utilization. We optimize and extend OS memory subsystem for better supporting applications while addressing three memory-related issues in data-intensive applications. First, we introduce a memory-efficient cooperative caching approach between application and kernel buffer to address double caching problem where the same data resides in multiple layers. Second, we present a memory-efficient, transparent zero-copy read I/O scheme to avoid the performance interference problem caused by memory copy behavior during I/O. Third, we propose a memory-efficient fork-based checkpointing mechanism for in-memory database systems to mitigate the memory footprint problem of the existing fork-based checkpointing scheme; memory usage increases incrementally (up to 2x) during checkpointing for update-intensive workloads. To show the effectiveness of our approach, we implement and evaluate our schemes on real multi-core systems. The experimental results demonstrate that our cooperative approach can more effectively address the above issues related to data-intensive applications than existing non-cooperative approaches while delivering better performance (in terms of transaction processing speed, I/O throughput, or memory footprint).์ตœ๊ทผ ํญ๋ฐœ์ ์ธ ๋ฐ์ดํ„ฐ ์„ฑ์žฅ๊ณผ ๋”๋ถˆ์–ด ๋ฐ์ดํ„ฐ๋ฒ ์ด์Šค, ํ‚ค-๋ฐธ๋ฅ˜ ์Šคํ† ๋ฆฌ์ง€ ๋“ฑ์˜ ๋ฐ์ดํ„ฐ ์ง‘์•ฝ์ ์ธ ์‘์šฉ๋“ค์ด ๋‹ค์–‘ํ•œ ๋„๋ฉ”์ธ์—์„œ ์ธ๊ธฐ๋ฅผ ์–ป๊ณ  ์žˆ๋‹ค. ๋ฐ์ดํ„ฐ ์ง‘์•ฝ์ ์ธ ์‘์šฉ์˜ ๋†’์€ ์„ฑ๋Šฅ ์š”๊ตฌ๋ฅผ ์ถฉ์กฑํ•˜๊ธฐ ์œ„ํ•ด์„œ๋Š” ์ฃผ์–ด์ง„ ๋ฉ”๋ชจ๋ฆฌ ์ž์›์„ ํšจ์œจ์ ์ด๊ณ  ์™„๋ฒฝํ•˜๊ฒŒ ํ™œ์šฉํ•˜๋Š” ๊ฒƒ์ด ์ค‘์š”ํ•˜๋‹ค. ๊ทธ๋Ÿฌ๋‚˜, ๋ฒ”์šฉ ์šด์˜์ฒด์ œ(OS)๋Š” ์‹œ์Šคํ…œ์—์„œ ์ˆ˜ํ–‰ ์ค‘์ธ ๋ชจ๋“  ์‘์šฉ๋“ค์— ๋Œ€ํ•ด ์‹œ์Šคํ…œ ์ฐจ์›์—์„œ ๊ณตํ‰ํ•˜๊ฒŒ ์ž์›์„ ์ œ๊ณตํ•˜๋Š” ๊ฒƒ์„ ์šฐ์„ ํ•˜๋„๋ก ์„ค๊ณ„๋˜์–ด์žˆ๋‹ค. ์ฆ‰, ์‹œ์Šคํ…œ ์ฐจ์›์˜ ๊ณตํ‰์„ฑ ์œ ์ง€๋ฅผ ์œ„ํ•œ ์šด์˜์ฒด์ œ ์ง€์›์˜ ํ•œ๊ณ„๋กœ ์ธํ•ด ๋‹จ์ผ ์‘์šฉ์€ ์‹œ์Šคํ…œ์˜ ์ตœ๊ณ  ์„ฑ๋Šฅ์„ ์™„์ „ํžˆ ํ™œ์šฉํ•˜๊ธฐ ์–ด๋ ต๋‹ค. ์ด๋Ÿฌํ•œ ์ด์œ ๋กœ, ๋งŽ์€ ๋ฐ์ดํ„ฐ ์ง‘์•ฝ์  ์‘์šฉ์€ ์šด์˜์ฒด์ œ์—์„œ ์ œ๊ณตํ•˜๋Š” ๊ธฐ๋Šฅ์— ์˜์ง€ํ•˜์ง€ ์•Š๊ณ  ๋น„์Šทํ•œ ๊ธฐ๋Šฅ์„ ์‘์šฉ ๋ ˆ๋ฒจ์— ๊ตฌํ˜„ํ•˜๊ณค ํ•œ๋‹ค. ์ด๋Ÿฌํ•œ ์ ‘๊ทผ ๋ฐฉ๋ฒ•์€ ํƒ์š•์ ์ธ ์ตœ์ ํ™”๊ฐ€ ๊ฐ€๋Šฅํ•˜๋‹ค๋Š” ์ ์—์„œ ์„ฑ๋Šฅ ์ƒ ์ด๋“์ด ์žˆ์„ ์ˆ˜ ์žˆ์ง€๋งŒ, ์‹œ์Šคํ…œ ์ž์›์˜ ๋น„ํšจ์œจ์ ์ธ ์‚ฌ์šฉ์„ ์ดˆ๋ž˜ํ•  ์ˆ˜ ์žˆ๋‹ค. ๋ณธ ๋…ผ๋ฌธ์—์„œ๋Š” ์šด์˜์ฒด์ œ์˜ ์ง€์›๊ณผ ์•ฝ๊ฐ„์˜ ์‘์šฉ ์ˆ˜์ •๋งŒ์œผ๋กœ๋„ ๋น„ํšจ์œจ์ ์ธ ์‹œ์Šคํ…œ ์ž์› ์‚ฌ์šฉ ์—†์ด ๋ณด๋‹ค ๋†’์€ ์‘์šฉ ์„ฑ๋Šฅ์„ ๋ณด์ผ ์ˆ˜ ์žˆ์Œ์„ ์ฆ๋ช…ํ•˜๊ณ ์ž ํ•œ๋‹ค. ๊ทธ๋Ÿฌ๊ธฐ ์œ„ํ•ด ์šด์˜์ฒด์ œ์˜ ๋ฉ”๋ชจ๋ฆฌ ์„œ๋ธŒ์‹œ์Šคํ…œ์„ ์ตœ์ ํ™” ๋ฐ ํ™•์žฅํ•˜์—ฌ ๋ฐ์ดํ„ฐ ์ง‘์•ฝ์ ์ธ ์‘์šฉ์—์„œ ๋ฐœ์ƒํ•˜๋Š” ์„ธ ๊ฐ€์ง€ ๋ฉ”๋ชจ๋ฆฌ ๊ด€๋ จ ๋ฌธ์ œ๋ฅผ ํ•ด๊ฒฐํ•˜์˜€๋‹ค. ์ฒซ์งธ, ๋™์ผํ•œ ๋ฐ์ดํ„ฐ๊ฐ€ ์—ฌ๋Ÿฌ ๊ณ„์ธต์— ์กด์žฌํ•˜๋Š” ์ค‘๋ณต ์บ์‹ฑ ๋ฌธ์ œ๋ฅผ ํ•ด๊ฒฐํ•˜๊ธฐ ์œ„ํ•ด ์‘์šฉ๊ณผ ์ปค๋„ ๋ฒ„ํผ ๊ฐ„์— ๋ฉ”๋ชจ๋ฆฌ ํšจ์œจ์ ์ธ ํ˜‘๋ ฅ ์บ์‹ฑ ๋ฐฉ์‹์„ ์ œ์‹œํ•˜์˜€๋‹ค. ๋‘˜์งธ, ์ž…์ถœ๋ ฅ์‹œ ๋ฐœ์ƒํ•˜๋Š” ๋ฉ”๋ชจ๋ฆฌ ๋ณต์‚ฌ๋กœ ์ธํ•œ ์„ฑ๋Šฅ ๊ฐ„์„ญ ๋ฌธ์ œ๋ฅผ ํ”ผํ•˜๊ธฐ ์œ„ํ•ด ๋ฉ”๋ชจ๋ฆฌ ํšจ์œจ์ ์ธ ๋ฌด๋ณต์‚ฌ ์ฝ๊ธฐ ์ž…์ถœ๋ ฅ ๋ฐฉ์‹์„ ์ œ์‹œํ•˜์˜€๋‹ค. ์…‹์งธ, ์ธ-๋ฉ”๋ชจ๋ฆฌ ๋ฐ์ดํ„ฐ๋ฒ ์ด์Šค ์‹œ์Šคํ…œ์„ ์œ„ํ•œ ๋ฉ”๋ชจ๋ฆฌ ํšจ์œจ์ ์ธ fork ๊ธฐ๋ฐ˜ ์ฒดํฌํฌ์ธํŠธ ๊ธฐ๋ฒ•์„ ์ œ์•ˆํ•˜์—ฌ ๊ธฐ์กด ํฌํฌ ๊ธฐ๋ฐ˜ ์ฒดํฌํฌ์ธํŠธ ๊ธฐ๋ฒ•์—์„œ ๋ฐœ์ƒํ•˜๋Š” ๋ฉ”๋ชจ๋ฆฌ ์‚ฌ์šฉ๋Ÿ‰ ์ฆ๊ฐ€ ๋ฌธ์ œ๋ฅผ ์™„ํ™”ํ•˜์˜€๋‹ค; ๊ธฐ์กด ๋ฐฉ์‹์€ ์—…๋ฐ์ดํŠธ ์ง‘์•ฝ์  ์›Œํฌ๋กœ๋“œ์— ๋Œ€ํ•ด ์ฒดํฌํฌ์ธํŒ…์„ ์ˆ˜ํ–‰ํ•˜๋Š” ๋™์•ˆ ๋ฉ”๋ชจ๋ฆฌ ์‚ฌ์šฉ๋Ÿ‰์ด ์ตœ๋Œ€ 2๋ฐฐ๊นŒ์ง€ ์ ์ง„์ ์œผ๋กœ ์ฆ๊ฐ€ํ•  ์ˆ˜ ์žˆ์—ˆ๋‹ค. ๋ณธ ๋…ผ๋ฌธ์—์„œ๋Š” ์ œ์•ˆํ•œ ๋ฐฉ๋ฒ•๋“ค์˜ ํšจ๊ณผ๋ฅผ ์ฆ๋ช…ํ•˜๊ธฐ ์œ„ํ•ด ์‹ค์ œ ๋ฉ€ํ‹ฐ ์ฝ”์–ด ์‹œ์Šคํ…œ์— ๊ตฌํ˜„ํ•˜๊ณ  ๊ทธ ์„ฑ๋Šฅ์„ ํ‰๊ฐ€ํ•˜์˜€๋‹ค. ์‹คํ—˜๊ฒฐ๊ณผ๋ฅผ ํ†ตํ•ด ์ œ์•ˆํ•œ ํ˜‘๋ ฅ์  ์ ‘๊ทผ๋ฐฉ์‹์ด ๊ธฐ์กด์˜ ๋น„ํ˜‘๋ ฅ์  ์ ‘๊ทผ๋ฐฉ์‹๋ณด๋‹ค ๋ฐ์ดํ„ฐ ์ง‘์•ฝ์  ์‘์šฉ์—๊ฒŒ ํšจ์œจ์ ์ธ ๋ฉ”๋ชจ๋ฆฌ ์ž์› ํ™œ์šฉ์„ ๊ฐ€๋Šฅํ•˜๊ฒŒ ํ•จ์œผ๋กœ์จ ๋” ๋†’์€ ์„ฑ๋Šฅ์„ ์ œ๊ณตํ•  ์ˆ˜ ์žˆ์Œ์„ ํ™•์ธํ•  ์ˆ˜ ์žˆ์—ˆ๋‹ค.Chapter 1 Introduction 1 1.1 Motivation 1 1.1.1 Importance of Memory Resources 1 1.1.2 Problems 2 1.2 Contributions 5 1.3 Outline 6 Chapter 2 Background 7 2.1 Linux Kernel Memory Management 7 2.1.1 Page Cache 7 2.1.2 Page Reclamation 8 2.1.3 Page Table and TLB Shootdown 9 2.1.4 Copy-on-Write 10 2.2 Linux Support for Applications 11 2.2.1 fork 11 2.2.2 madvise 11 2.2.3 Direct I/O 12 2.2.4 mmap 13 Chapter 3 Memory Efficient Cooperative Caching 14 3.1 Motivation 14 3.1.1 Problems of Existing Datastore Architecture 14 3.1.2 Proposed Architecture 17 3.2 Related Work 17 3.3 Design and Implementation 19 3.3.1 Overview 19 3.3.2 Kernel Support 24 3.3.3 Migration to DBIO 25 3.4 Evaluation 27 3.4.1 System Configuration 27 3.4.2 Methodology 28 3.4.3 TPC-C Benchmarks 30 3.4.4 YCSB Benchmarks 32 3.5 Summary 37 Chapter 4 Memory Efficient Zero-copy I/O 38 4.1 Motivation 38 4.1.1 The Problems of Copy-Based I/O 38 4.2 Related Work 40 4.2.1 Zero Copy I/O 40 4.2.2 TLB Shootdown 42 4.2.3 Copy-on-Write 43 4.3 Design and Implementation 44 4.3.1 Prerequisites for z-READ 44 4.3.2 Overview of z-READ 45 4.3.3 TLB Shootdown Optimization 48 4.3.4 Copy-on-Write Optimization 52 4.3.5 Implementation 55 4.4 Evaluation 55 4.4.1 System Configurations 56 4.4.2 Effectiveness of the TLB Shootdown Optimization 57 4.4.3 Effectiveness of CoW Optimization 59 4.4.4 Analysis of the Performance Improvement 62 4.4.5 Performance Interference Intensity 63 4.4.6 Effectiveness of z-READ in Macrobenchmarks 65 4.5 Summary 67 Chapter 5 Memory Efficient Fork-based Checkpointing 69 5.1 Motivation 69 5.1.1 Fork-based Checkpointing 69 5.1.2 Approach 71 5.2 Related Work 73 5.3 Design and Implementation 74 5.3.1 Overview 74 5.3.2 OS Support 78 5.3.3 Implementation 79 5.4 Evaluation 80 5.4.1 Experimental Setup 80 5.4.2 Performance 81 5.5 Summary 86 Chapter 6 Conclusion 87 ์š”์•ฝ 100Docto

    Prototyping of CMS storage management

    Get PDF

    An efficient storage manager

    No full text
    When dealing with large quantities of clauses, the use of persistent knowledge is inevitable, and indexing methods are essential to answer queries efficiently. We introduce PerKMan, a storage manager that uses G-trees and aims at efficient manipulation of large amount of persistent knowledge. PerKMan may be connected to Prolog systems that offer an external C language interface. As well as the fact that the storage manager allows different arguments of a predicate to share a common index dimension in a novel manner, it indexes rules and facts in the same manner. PerKMan handles compound terms efficiently and its data structures adapt their shape to large dynamic volumes of clauses, no matter what their distribution. The storage manager achieves fast clause retrieval and reasonable use of disk space. ยฉ Springer-Verlag Berlin Heidelberg 2000

    Thresher: An efficient storage manager for copy-on-write snapshots

    No full text
    A new generation of storage systems exploit decreasing storage costs to allow applications to take snapshots of past states and retain them for long durations. Over time, current snapshot techniques can produce large volumes of snapshots. Indiscriminately keeping all snapshots accessible is impractical, even if raw disk storage is cheap, because administering such large-volume storage is expensive over a long duration. Moreover, not all snapshots are equally valuable. Thresher is a new snapshot storage management system, based on novel copyon-write snapshot techniques, that is the first to provide applications the ability to discriminate among snapshots efficiently. Valuable snapshots can remain accessible or stored with faster access while less valuable snapshots are discarded or moved off-line. Measurements of the Thresher prototype indicate that the new techniques are efficient and scalable, imposing minimal (4%) performance penalty on expected common workloads.

    Data Models, Query Execution, and Storage for Traditional & Immersive Video Data Management

    No full text
    Thesis (Ph.D.)--University of Washington, 2020The proliferation of cameras deployed throughout our world is enabling and accelerating exciting new applications such as virtual and augmented reality (VR and AR), autonomous driving, drone analytics, and smart infrastructure. However, these cameras collectively produce staggering quantities of video data. VR spherical (360ร‚ยฐ) video is up to 20x larger in size than its 2D counterparts. Closed-circuit television camera networks, consisting of tens of thousands of cameras, generate petabytes of video data per day. A single autonomous vehicle can generate tens of terabytes of video data per hour. Due to these massive data sizes and the complexity involved with reasoning about large numbers of cameras, developing applications that use real world video data remains challenging. Developers must be cognizant of the low-level storage intricacies of video formats and compression. They need expertise in device-specific programming (e.g., GPUs), and, to maximize performance, they must be able to balance execution across heterogeneous, possibly distributed hardware. In this thesis, we describe several video data management systems designed to simplify application development, optimize execution, evaluate performance, and move forward the state of the art in video data management. The first system, LightDB, presents a simple, declarative interface for VR and AR video application development. It implements powerful query optimization techniques, an efficient storage manager, and a suite of novel physical optimizations. To further improve the performance of video applications, we next introduce a new video file system (VFS), which can serve as a storage manager for video data management systems (such as LightDB and others) or can be used as a standalone system. It is designed to decouple video application design from a video's underlying physical layout and compressed format. Finally, analogous to standardized benchmarks for other areas of data management research, we develop a new benchmark--Visual Road--aimed specifically at evaluating the performance and scalability of video-oriented data management systems and frameworks. By exposing declarative interfaces, LightDB and VFS automatically produce efficient execution strategies that include leveraging heterogeneous hardware, operating directly on the compressed representation of video data, and improving video storage performance. Visual Road reproducibly and objectively measures how well a video system or framework executes a battery of microbenchmarks real-world video-oriented workloads. Collectively through these systems, we show that the application of fundamental data management principles to this space vastly improves runtime performance (by up to 500x), storage performance (up to 45% decrease in file sizes), and greatly decreases application development complexity (decreasing lines of code by up to 90%)
    corecore