Подтвердить что ты не робот

Почему моя реализация Mapreduce (реальный мир haskell) с использованием iteratee IO также терпит неудачу с "Слишком много открытых файлов",

Я реализую программу haskell, которая сравнивает каждую строку файла с каждой другой линией в файле. Который может быть реализован с одиночной резьбой следующим образом

distance :: Int -> Int -> Int
distance a b = (a-b)*(a-b)

sumOfDistancesOnSmallFile :: FilePath -> IO Int
sumOfDistancesOnSmallFile path = do
              fileContents <- readFile path
              return $ allDistances $ map read $ lines $ fileContents
              where
                  allDistances (x:xs) = (allDistances xs) + ( sum $ map (distance x) xs)
                  allDistances _ = 0

Это будет работать в O (n ^ 2) времени и должно содержать полный список целых чисел в памяти все время. В моей реальной программе строка содержит больше чисел, из которых я строю немного сложный тип данных, чем Int. Это привело к ошибкам памяти для данных, которые я должен обработать.

Таким образом, есть два улучшения в вышеупомянутом однопоточном решении. Во-первых, ускорьте фактическое время работы. Во-вторых, найдите способ не хранить весь список в памяти на полный рабочий день. Я знаю, что это требует разбора полного файла n раз. Таким образом, будет проведено сравнение O (n ^ 2) и проанализированы строки O (n ^ 2). Это нормально для меня, поскольку я предпочел бы медленную успешную программу, чем неудачная программа. Когда входной файл достаточно мал, я всегда могу найти более простую версию.

Чтобы использовать несколько ядер процессора, я взял реализацию Mapreduce из Real World Haskell (глава 24, доступная здесь).

Я изменил функцию chunking из книги, вместо того, чтобы делить полный файл на куски, вернуть столько кусков, сколько строк с каждым фрагментом, представляющим один элемент

tails . lines . readFile

Поскольку я хочу, чтобы программа также была масштабируемой в размере файла, я изначально использовал lazy IO. Однако это приводит к сбою "Слишком много открытых файлов" , о чем я спросил в предыдущем вопросе (файлы обрабатывались слишком поздно GC). Полная ленивая версия IO размещена там.

Как объясняет принятый ответ, строгий IO может решить проблему. Это действительно решает проблему "Слишком много открытых файлов" для файлов строк 2k, но не получается "из памяти" в файле 50k.

Обратите внимание, что первая реализация однопоточная (без mapreduce) способна обрабатывать файл 50k.

Альтернативное решение, которое мне больше всего нравится, заключается в использовании iteratee IO. Я ожидал, что это решит как дескриптор файла, так и ресурс памяти. Однако моя реализация все еще не выполняется с ошибкой "Слишком много открытых файлов" в файле строки 2k.

Итерационная версия IO имеет ту же функцию mapReduce, что и в книге, но имеет модифицированный chunkedFileEnum, позволяющий ей работать с Enumerator.

Таким образом, мой вопрос: что не так со следующей итерационной базой IO? Где Лень?.

import Control.Monad.IO.Class (liftIO)
import Control.Monad.Trans (MonadIO, liftIO)
import System.IO

import qualified Data.Enumerator.List as EL
import qualified Data.Enumerator.Text as ET
import Data.Enumerator hiding (map, filter, head, sequence)

import Data.Text(Text)
import Data.Text.Read
import Data.Maybe

import qualified Data.ByteString.Char8 as Str
import Control.Exception (bracket,finally)
import Control.Monad(forM,liftM)
import Control.Parallel.Strategies
import Control.Parallel
import Control.DeepSeq (NFData)
import Data.Int (Int64)

--Goal: in a file with n values, calculate the sum of all n*(n-1)/2 squared distances

--My operation for one value pair
distance :: Int -> Int -> Int
distance a b = (a-b)*(a-b)

combineDistances :: [Int] -> Int
combineDistances = sum

--Test file generation
createTestFile :: Int -> FilePath -> IO ()
createTestFile n path = writeFile path $ unlines $ map show $ take n $ infiniteList 0 1
        where infiniteList :: Int->Int-> [Int]
              infiniteList i j = (i + j) : infiniteList j (i+j)

--Applying my operation simply on a file 
--(Actually does NOT throw an Out of memory on a file generated by createTestFile 50000)
--But i want to use multiple cores..
sumOfDistancesOnSmallFile :: FilePath -> IO Int
sumOfDistancesOnSmallFile path = do
                  fileContents <- readFile path
                  return $ allDistances $ map read $ lines $ fileContents
                  where
                      allDistances (x:xs) = (allDistances xs) + ( sum $ map (distance x)    xs)
                      allDistances _ = 0

--Setting up an enumerator of read values from a text stream
readerEnumerator :: Monad m =>Integral a => Reader a -> Step a m b -> Iteratee Text m b
readerEnumerator reader = joinI . (EL.concatMapM transformer)
                            where transformer input = case reader input of
                                         Right (val, remainder) -> return [val]
                                         Left err -> return [0]

readEnumerator :: Monad m =>Integral a => Step a m b -> Iteratee Text m b
readEnumerator = readerEnumerator (signed decimal)

--The iteratee version of my operation
distancesFirstToTailIt :: Monad m=> Iteratee Int m Int
distancesFirstToTailIt = do
    maybeNum <- EL.head
    maybe (return 0) distancesOneToManyIt maybeNum

distancesOneToManyIt :: Monad m=> Int -> Iteratee Int m Int
distancesOneToManyIt base = do
    maybeNum <- EL.head
    maybe (return 0) combineNextDistance maybeNum
    where combineNextDistance nextNum = do
              rest <- distancesOneToManyIt base
              return $ combineDistances [(distance base nextNum),rest]

--The mapreduce algorithm
mapReduce :: Strategy b -- evaluation strategy for mapping
          -> (a -> b)   -- map function
          -> Strategy c -- evaluation strategy for reduction
          -> ([b] -> c) -- reduce function
          -> [a]        -- list to map over
          -> c
mapReduce mapStrat mapFunc reduceStrat reduceFunc input =
          mapResult `pseq` reduceResult
          where mapResult    = parMap mapStrat mapFunc input
                reduceResult = reduceFunc mapResult `using` reduceStrat

--Applying the iteratee operation using mapreduce
sumOfDistancesOnFileWithIt :: FilePath -> IO Int
sumOfDistancesOnFileWithIt path = chunkedFileEnum chunkByLinesTails (distancesUsingMapReduceIt) path

distancesUsingMapReduceIt :: [Enumerator Text IO Int] -> IO Int
distancesUsingMapReduceIt = mapReduce rpar (runEnumeratorAsMapFunc)
                                      rpar (sumValuesAsReduceFunc)
                            where runEnumeratorAsMapFunc :: Enumerator Text IO Int -> IO Int
                                  runEnumeratorAsMapFunc = (\source->run_ (source $$ readEnumerator $$ distancesFirstToTailIt))
                                  sumValuesAsReduceFunc :: [IO Int] -> IO Int
                                  sumValuesAsReduceFunc = liftM sum . sequence


--Working with (file)chunk enumerators:
data ChunkSpec = CS{
    chunkOffset :: !Int
    , chunkLength :: !Int
    } deriving (Eq,Show)

chunkedFileEnum ::   (NFData (a)) => MonadIO m =>
                (FilePath-> IO [ChunkSpec])
           ->   ([Enumerator Text m b]->IO a)
           ->   FilePath
           ->   IO a
chunkedFileEnum chunkCreator funcOnChunks path = do
    (chunks, handles)<- chunkedEnum chunkCreator path
    r <- funcOnChunks chunks
    (rdeepseq r `seq` (return r)) `finally` mapM_ hClose handles

chunkedEnum ::  MonadIO m=>
                (FilePath -> IO [ChunkSpec])
            ->  FilePath
            ->  IO ([Enumerator Text m b], [Handle])
chunkedEnum chunkCreator path = do
    chunks <- chunkCreator path
    liftM unzip . forM chunks $ \spec -> do
        h <- openFile path ReadMode
        hSeek h AbsoluteSeek (fromIntegral (chunkOffset spec))
        let chunk = ET.enumHandle h --Note:chunklength not taken into account, so just to EOF
        return (chunk,h)

-- returns set of chunks representing  tails . lines . readFile 
chunkByLinesTails :: FilePath -> IO[ChunkSpec]
chunkByLinesTails path = do
    bracket (openFile path ReadMode) hClose $ \h-> do
        totalSize <- fromIntegral `liftM` hFileSize h
        let chunkSize = 1
            findChunks offset = do
            let newOffset = offset + chunkSize
            hSeek h AbsoluteSeek (fromIntegral newOffset)
            let findNewline lineSeekOffset = do
                eof <- hIsEOF h
                if eof
                    then return [CS offset (totalSize - offset)]
                    else do
                        bytes <- Str.hGet h 256
                        case Str.elemIndex '\n' bytes of
                            Just n -> do
                                nextChunks <- findChunks (lineSeekOffset + n + 1)
                                return (CS offset (totalSize-offset):nextChunks)
                            Nothing -> findNewline (lineSeekOffset + Str.length bytes)
            findNewline newOffset
        findChunks 0

Btw, я бегу HaskellPlatform 2011.2.0 на Mac OS X 10.6.7 (снежный барс)
со следующими пакетами:
bytestring 0.9.1.10
параллельный 3.1.0.1
перечислитель 0.4.8, с руководством здесь

4b9b3361

ОТВЕТЫ

Ответ 1

Как говорится в ошибке, слишком много открытых файлов. Я ожидал, что Haskell будет запускать большую часть программы последовательно, но некоторые "искры" параллельны. Однако, как упоминалось выше, Haskell всегда искривляет оценки.

Это обычно не проблема в чистой функциональной программе, но это когда вы работаете с IO (ресурсами). Я масштабировал parallelism, как описано в книге Real World Haskell слишком далеко. Поэтому мой вывод состоит в том, чтобы сделать parallelism только в ограниченном масштабе при работе с ресурсами ввода-вывода в искрых. В чистой функциональной части может произойти чрезмерное parallelism.

Таким образом, ответ на мой пост - не использовать MapReduce для всей программы, а внутри внутренней чистой функциональной части.

Чтобы показать, где программа действительно не удалось, я настроил ее с помощью -enable-executable-profiling -p, построил ее и запустил с помощью + RTS -p -hc -L30. Поскольку исполняемый файл не работает немедленно, профиль распределения памяти отсутствует. Результирующий профиль распределения времени в файле .prof начинается со следующего:

                                                                                               individual    inherited
COST CENTRE              MODULE                                               no.    entries  %time %alloc   %time %alloc

MAIN                     MAIN                                                   1            0   0.0    0.3   100.0  100.0
  main                    Main                                                1648           2   0.0    0.0    50.0   98.9
    sumOfDistancesOnFileWithIt MapReduceTest                                  1649           1   0.0    0.0    50.0   98.9
      chunkedFileEnum       MapReduceTest                                     1650           1   0.0    0.0    50.0   98.9
        chunkedEnum          MapReduceTest                                    1651         495   0.0   24.2    50.0   98.9
          lineOffsets         MapReduceTest                                   1652           1  50.0   74.6    50.0   74.6

chunkedEnum возвращает IO ([Enumerator Text m b], [Handle]) и, по-видимому, получает 495 записей. Входной файл был файлом строки 2k, поэтому единственная запись в lineOffsets вернула список смещений 2000. В distancesUsingMapReduceIt нет ни одной записи, поэтому фактическая работа даже не началась!